Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/04/17 15:12, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 10, 2017 at 02:28:58PM +0100, Wei Liu wrote:
>> On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
>>> On 10/04/17 12:24, lidonglin wrote:
>>>> Hi all:
>>>>
>>>>                 I have one question about PCI passthrough. I found
>>>> that if I created a VM with host pci device(cfg file as below), there
>>>> were some xenstore keys exsiting in /local/domain/0 and
>>>> /local/domain/DomID/. Besides I found one unknown device in device
>>>> manager of Windows OS with Class ID FF80 from vendor ID 5853. My
>>>> questions  are as below:
>>>>
>>>>  
>>>>
>>>> 1.       Why do we create frontend and backend key pairs in xenstore?
>>>>  I think  Passthrough is not PV,  was it possible that we just used
>>>> these keys to record something?
>>>>
>>>> 2.        After review the code, I think backend keys are used to
>>>> record state of hostdev, some codes will query something using these
>>>> keys. But for frontend keys, can we delete them?
>>>>
>>>> 3.       if frontend keys exist in xenstore, then unknown device will
>>>> appear in device manager. Can we fix this?  For  an obsessive,  he
>>>> can’t stand for this.
>>>>
>>> This is a libxl bug which has been reported before, but nothing happened.
>>>
>>> libxl must not start a PV pci-back when doing HVM PCI passthrough using
>>> qemu, because absolutely nothing good can come of having two different
>>> ways of poking at PCI state.
>>>
>>> The patch, unchanged from before, is
>>> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
>>>
>> ISTR Konrad made some comments about it. CC Konrad.
> Aye. My primary beef was that you need some FLR mechanism and pciback
> does that. The 'do_flr' was the solution to that - as you could
> effectively do it via an ioctl and all would be good.
>
> Except I am probably missing some edge case (like guest is killed
> and we need to do an FLR again, or there are AERs to deal with, etc) so
> some pciback -> xenstore -> libxl needs to be in place even for HVM guests.
>
> Just disabling pciback for HVM does not solve the problem that:
>
>  - We need FLR
>  - We need AER support (CC-ing Venu who is working on this for libxl/pciback)

The problem is that pciback is two distinct pieces of functionality.  It
should be split in half, so the "steal a device from its real driver and
provide reset functionality" is purposefully separate from "be the
reverse half the PV interface".

Qemu has no problems with resetting the device when necessary, though,
which is why this patch functions perfectly well in a real system.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel