Xen Guru group | XCP-ng and XO forum

andSmv

@Niall-Con Thank you! I'll take a look to that and will ping you to test on real hardware. Just need to find time (in the middle of storm right now), so it'll take one or two weeks most probably.

andSmv

Hello,

Yes, unfortunately this is a PCIe device and this is also a PCIe capability which is reported in PCI extended configuration space (offset 0x100) and not covered by standard PCI configuration access method. And visibly the driver NEEDS this cap to make the device work.

Actually there's a work in progress (very close to its end) which offers to HVM guests a QEMU emulated Q35 chipset (instead of currently emulated i440fx chipset). This chipset "provide" to guest (amongst other things) an emulated PCI-e bus, which is capable to host PCIe devices and also offers an access to PCI extended configuration space.

When this work is done we will be able to passthrough PCIe devices and provide access to guest to all PCIe caps, so normally no driver would complain about missing that.

AFIAK, "most common" PCIe caps are emulated in this future patchset, but it still will be possible that some of them are not (exotic ones).

For now, i ping @ThierryEscande to see if he can provide to you a beta version of this patches, to see if it solves your problem and if you're agree to do some tests by the same occasion

dinhngtu

@bberndt Autoreboot works, but one issue is that you don't have policy-based control over when it reboots (unlike Windows Update). If that's important for you I'd recommend applying the guest agent+driver updates during a dedicated patch window, and setting the VMs to autoreboot only during that window.

I'd very much appreciate having people use the new XCP-ng drivers (which are stable & reliable despite the current lack of Microsoft signatures, and come with a few nice extras) but I get that it's not always possible. Without the necessary Microsoft hardware accounts it's hard to give a concrete timeline, but I'd like to believe it'll happen soon.

dinhngtu

@bberndt

So there are 2 parts to be aware of:

The PV I/O drivers which are pulled from/updated by Windows Update;
The management agent which you get from XenServer. This has its own update platform that you can enable at install time.

Confusingly the XenServer management agent also has an option to install PV I/O drivers by itself without going through Windows Update at all. (This is why they state "Customers using Windows Update for I/O driver updates should not select this option)

I'm not sure what you mean by not getting updates? Even our unsigned drivers do get updates, bug fixes etc. and this will continue once a signed version comes out.
For the final signed version, at the moment we're still waiting for authorization from Microsoft (they work extremely slowly and we've run into all sorts of problems with their developer program)

dinhngtu

@andriy.sultanov Setting it above 16 immediately broke Windows for me.

andSmv

@milch I will take a look this week and try to figure out if we can make progress on that, so you could have something to test.

andSmv

Just got the answer from Marek on that. The patches he made was tested with Intel Wifi cards and was targeting the similar issue (MSI-x table) but not the same as Coral TPU (PBA). It should be not very very difficult to extend his patches to the PBA, but unfortunately neither him (neither us) don't have this specific hardware.

The patches he made are actually upstream b2cd07a0447bfa25e96ae13e190225b61a3670cb so you can take a look at it if you want.

I will try to see if we have an easy possibility to get this HW

dinhngtu

@hypernoob That's just the key's name, I use keys with long complicated names too and had no problem. What did ssh -vv tell you?

dinhngtu

@hypernoob I suggest this procedure instead:

Get the Debian genericcloud QCOW2 image off of here: https://cdimage.debian.org/images/cloud/
Convert to VHD: qemu-img convert -O vpc debian-12-genericcloud-amd64.qcow2 debian-12-genericcloud-amd64.vhd
Import the converted VHD into XO
Attach to empty Debian VM, set to boot from hard drive and convert to template
Create new VMs from this template, adding your ssh keys and guest agent in cloud config if desired:

#cloud-config
hostname: {name}
ssh_authorized_keys:
  - ssh-rsa ...
apt:
  sources:
    xen-guest-agent:
      filename: xen-guest-agent.list
      source: deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project%252Fxen-guest-agent/packages/generic/deb-amd64/ release/
      append: false
packages:
  - xen-guest-agent

The same procedure will work with Ubuntu, Alma and other cloud images.

Xen Guru

Posts

Member List

T	ThierryEscande
D	dinhngtu
T	TeddyAstie
A	anthonyper
A	andSmv
A	andyhhp