xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>,
	Kevin Stange <kevin@steadfast.net>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: PCI Device Subtree Change from Traditional to Upstream
Date: Thu, 25 Jan 2018 17:54:36 +0000	[thread overview]
Message-ID: <10c96acc-9bb5-713b-93c9-60f06c84bfd5@citrix.com> (raw)
In-Reply-To: <20180104125217.GB1905@perard.uk.xensource.com>

On 01/04/2018 12:52 PM, 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@citrix.com>
>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>>  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
> 
> 
> 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.
> 
> 
> From: Anthony PERARD <anthony.perard@citrix.com>
> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3
> 
> In order to do that, we don't use xenfv machine anymore and explicity
> add the platform device on the command line.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Anthony,

It seems like we might want to add the ability to specify which slot we
want the xen-platform device to occupy. Is it worth thinking of the best
way to add a patch like this upstream?

 -George

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

  parent reply	other threads:[~2018-01-25 17:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 17:40 PCI Device Subtree Change from Traditional to Upstream Kevin Stange
2017-12-20 17:44 ` George Dunlap
2018-01-03 17:57 ` Anthony PERARD
2018-01-03 23:10   ` Kevin Stange
2018-01-04 12:52     ` Anthony PERARD
2018-01-04 13:26       ` Paul Durrant
2018-01-04 21:17         ` Kevin Stange
2018-01-05  9:03           ` Paul Durrant
2018-01-05 17:05             ` Kevin Stange
2018-01-04 21:16       ` Kevin Stange
2018-01-05 17:10         ` Kevin Stange
2018-01-05 20:56           ` Kevin Stange
2018-01-25 17:54       ` George Dunlap [this message]
2018-01-25 18:04         ` Anthony PERARD
2018-01-25 18:14           ` George Dunlap
2018-01-26 10:38             ` Paul Durrant
2019-04-08  9:46               ` George Dunlap
2019-04-08  9:46                 ` [Xen-devel] " George Dunlap
2019-04-08  9:51                 ` Paul Durrant
2019-04-08  9:51                   ` [Xen-devel] " Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10c96acc-9bb5-713b-93c9-60f06c84bfd5@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=kevin@steadfast.net \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).