Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange <kevin@xxxxxxxxxxxxx>]

On 01/05/2018 11:10 AM, Kevin Stange wrote:
> On 01/04/2018 03:16 PM, Kevin Stange wrote:
>> On 01/04/2018 06:52 AM, Anthony PERARD wrote:
>>> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote:
>>>> On 01/03/2018 11:57 AM, Anthony PERARD wrote:
>>>>> On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've been working on transitioning a number of Windows guests under HVM
>>>>>> from using QEMU traditional to QEMU upstream as is recommended in the
>>>>>> documentation.  When I move these guests, the PCI subtree for Xen
>>>>>> devices changes and Windows creates a totally new copy of each device.
>>>>>> Windows tracks down the storage without issue, but it treats the new
>>>>>> instance of the NIC driver as a new device and clears the network
>>>>>> configuration even though the MAC address is unchanged.  Manually
>>>>>> booting the guest back on the traditional device model reactivates the
>>>>>> original PCI subtree and the old network configuration with it.
>>>>>>
>>>>>> The only thing that I have been able to find that's substantially
>>>>>> different comparing the device trees is that the device instance ID
>>>>>> values differ on the parent Xen PCI device:
>>>>>>
>>>>>> PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\3&267A616A&3&18
>>>>>>
>>>>>> PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\3&267A616A&3&10
>>>>>>
>>>>>> Besides actually setting the guest to boot using QEMU traditional, is
>>>>>> there a way to convince Windows to treat these devices as the same?  A
>>>>>> patch-based solution would be acceptable to me if there is one, but I
>>>>>> don't understand the code well enough to create my own solution.
>>>>>
>>>>> Hi Kevin,
>>>>>
>>>>> I've got a patch to QEMU that seems to do the trick:
>>>>>
>>>>> From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>>>
>>>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>>>> ---
>>>>>  hw/i386/pc_piix.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>>> index 5e47528993..93e3a9a916 100644
>>>>> --- a/hw/i386/pc_piix.c
>>>>> +++ b/hw/i386/pc_piix.c
>>>>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>>>>  
>>>>>      bus = pci_find_primary_bus();
>>>>>      if (bus != NULL) {
>>>>> -        pci_create_simple(bus, -1, "xen-platform");
>>>>> +        pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform");
>>>>>      }
>>>>>  }
>>>>>  #endif
>>>>>
>>>>>
>>>>> The same thing could be done by libxl, by providing specific command
>>>>> line options to qemu. (I think that could even be done via a different
>>>>> config file for the guest.)
>>>>
>>>> This patch doesn't seem to work for me.  It seems like the device model
>>>> process is exiting immediately, but I haven't been able to find any
>>>> information as to what is going wrong.  I tested with Xen 4.6.6 and the
>>>> QEMU packaged with that release.  Should I try it on a different version
>>>> of Xen and QEMU?
>>>
>>> What this patch does is asking QEMU to insert the PCI card
>>> "xen-platform" into the 3rd PCI slot. My guess is that failed because
>>> there is already a PCI device there.
>>>
>>> You could check qemu's logs, it's in
>>> /var/log/xen/qemu-dm-${guest_name}.log
>>
>> The log file in question only says:
>>
>> qemu: terminating on signal 1 from pid 8865
>>
>>> Let's try something else, instead of patching QEMU, we can patch libxl,
>>> that might work better. Can you try this patch? (I've only test
>>> compiled.) I've write the patch for Xen 4.6, since that the version you
>>> are using.
>>
>> This isn't doing the trick either, with the same misbehavior. The log
>> file is the same in both cases.
> 
> I'm getting confusing behavior here. I tried to boot a guest using a
> build with the second patch and behaves the way the first one did, with
> the qemu-system-i386 process exiting and preventing the guest from ever
> booting.  However, I tried to downgrade the packages to completely
> unpatched version in preparation to reboot again and once the older copy
> of the runtime is installed, the qemu-system-i386 starts properly using
> the command line arguments that libxl had specified and the system comes
> up with the correct PCI subtree.
> 
> This leads me to believe something about my build is screwed up somehow
> such that my qemu-system-i386 is broken.  I'm quite sure I'm not
> applying any extra patches to it that weren't otherwise in the CentOS
> virt packages.

George pointed me at the fact I had failed to pull in the seabios
package from CentOS virt.  The version from RHEL is broken and that was
my issue.  Sorry for generating extra noise as a result.

I can confirm that patch 2 (and probably patch 1, really) work around
the issue for me.  Thank you for the help!

It would be nice if there was a way to set default or override options
to domains from a configuration file that is read by libxl, qemu, or
libvirt but I see no code or documentation to support that right now.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
kevin@xxxxxxxxxxxxx | www.steadfast.net

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