Re: [Xen-devel] Test for osstest, features used in Qubes OS

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, May 17, 2018 at 08:00:38PM +0200, Sander Eikelenboom wrote:
> Marek / Ian,
> 
> Nice to see PCI-passthrough getting some attention again.
> 
> On 17/05/18 17:12, Ian Jackson wrote:
> > Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in 
> > Qubes OS"):
> >> On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote:
> >>> Is there some kind of cheap USB HID, that is interactable-with, which
> >>> we could plug into each machine's USB port ?  I'm slightly concerned
> >>> that plugging in a storage device, or connecting the other NIC, might
> >>> interfere with booting.
> >>
> >> I use mass storage for tests... But if you use network boot, it
> >> shouldn't really interfere, no?
> > 
> > We do both network boot and disk boot.  I think the BIOS disk boot has
> > to continue to work and boot the HDD.

In fact, using any device should be enough for the start. USB mouse for
example. Just reading USB descriptor involve some communication with the
controller, so it should be some indication about its state.

> As a user of pci-passthrough for quite some time and reporting some 
> pci-passthrough bugs in the past,
> I do have some comments:
> 
> - First of all it would be very nice to get some autotesting :).
> - But if you want to thoroughly test pci-passthrough, 
>   it will be far from easy since there is quite a multi-dimensional support 
> matrix
>   (I'm not implying that everything should be done or it won't be valuable if 
> any is missing,
>    it's only meant for reference):
>   1) Guest side implementation: 
>      - PV guest (pcifront)
>      - HVM (qemu-traditional) 
>      - HVM (qemu-xen) 
>      - HVM (qemu-upstream) 
>      - perhaps PVH support for pci passthrough coming around the corner.
> 
>   2) (Un)Binding method to pciback:
>      - binding pci devices to pciback on host boot (command line) 
>      - de/re/unbinding devices from dom0 while running.
>  
>   3) (Un)binding to guest:
>      - On guest start (guest.cfg pci=[...])
>      - After the guest has been started with 'xl pci-*' commands
>   3) Device interrupts: legacy versus MSI versus MSI-X
>   4) Other pci device features: roms, BAR sizes, etc.
>   5) AMD versus Intel IOMMU
> 
> From the past reports, I know (1) and (3) did matter (problems being isolated 
> to one of these variants only).

Yes, that's right, my experience is similar in that matter. Especially
point 3 is tricky/problematic, as some devices (or rather: drivers)
doesn't correctly fallback to legacy interrupts if MSI/MSI-X isn't
available.
So, the ideal test should check those things too - if the guest driver
really use what it's expected to use. But lets start with something
first. I don't know how osstest handle it yet, but I'd expect adding
more guest configurations to run the same test on should be easy.

> As for restarting guests and reassigning pci-devices again to other guests 
> the current pciback reset support lacks
> the bus-reset patches at present in upstream linux kernels. Passthrough of 
> AMD Radeon graphics adapters works only one
> time without it (if you stop and restart a guest it doesn't work anymore and 
> you need to reboot the host). 
> With the bus-reset patches (which have been posted to the list and seem to be 
> in both Qubes and Xenserver 
> in some form but not in upstream linux). Someone from Oracle had picked them 
> up to get them upstream some time ago,
> but that effort seems to have stalled.

Can you point specifically what patches are you talking about? In Qubes
in most cases device reset is handled by libvirt...

> The code in libxl seems to be quite messy for pci-passthrough especially for 
> handling all the guest side implementations (1)
> and xenstore interactions that go with it (or don't for qemu).
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel