Re: [Xen-devel] libvirt support for scheduler credit2
On 1/22/20 12:56 PM, Jim Fehlig wrote: > On 1/21/20 10:05 AM, Jürgen Groß wrote: >> On 21.01.20 17:56, Kevin Stange wrote: >>> Hi, >>> >>> I looked around a bit and wasn't able to find a good answer to this, so >>> George suggested I ask here. >> >> Cc-ing Jim. >> >>> >>> Since Xen 4.12, credit2 is the default scheduler, but at least as of >>> libvirt 5.1.0 virsh doesn't appear to understand credit2 and produces >>> this sort of output: > > You would see the same with libvirt.git master, sorry. ATM the libvirt libxl > driver is unaware of the credit2 scheduler. Hmm, as I recall Dario was going > to > provide a patch for libvirt :-). But he is quite busy so it will have to be > added to my very long todo list. Sorry to hear that's the case. Due to my orchestration system I'll have to hang on to credit a while longer. Thanks for clarifying! -- 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 ke...@steadfast.net | www.steadfast.net ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] libvirt support for scheduler credit2
Hi, I looked around a bit and wasn't able to find a good answer to this, so George suggested I ask here. Since Xen 4.12, credit2 is the default scheduler, but at least as of libvirt 5.1.0 virsh doesn't appear to understand credit2 and produces this sort of output: # xl sched-credit2 -d yw6hk7mo6zy3k8 NameID Weight Cap yw6hk7mo6zy3k8 4 100 # virsh schedinfo yw6hk7mo6zy3k8 Scheduler : credit2 Compared to a host running credit: # xl sched-credit -d gvz2b16sq38dv9 NameID Weight Cap gvz2b16sq38dv9 148000 # virsh schedinfo gvz2b16sq38dv9 Scheduler : credit weight : 800 cap: 0 Trying to change the weight does nothing, not even producing an error message: # virsh schedinfo syuxplsmdihcwc --weight 300 Scheduler : credit2 # xl sched-credit2 -d syuxplsmdihcwc NameID Weight Cap syuxplsmdihcwc 234000 Is there a version of libvirt where I can expect this to work, or is it not supported yet? As a workaround for now I've added sched=credit to my command line, but it would be nice to gain the benefits of improved scheduling at some point. -- 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 ke...@steadfast.net | www.steadfast.net ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
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_0001_00015853_01\3&267A616A&3&18
>>>>>>
>>>>>> PCI\VEN_5853_0001_00015853_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.per...@citrix.com>
>>>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>>>
>>>>> Signed-off-by: Anthony PERARD <anthony.per...@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
>>
>> 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.
&g
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
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_0001_00015853_01\3&267A616A&3&18
>>>>>
>>>>> PCI\VEN_5853_0001_00015853_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.per...@citrix.com>
>>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>>
>>>> Signed-off-by: Anthony PERARD <anthony.per...@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
>
> 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.
--
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
ke...@steadfast.net | www.steadfast.net
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
On 01/05/2018 03:03 AM, Paul Durrant wrote: >> -Original Message- >> From: Kevin Stange [mailto:ke...@steadfast.net] >> Sent: 04 January 2018 21:17 >> To: Paul Durrant <paul.durr...@citrix.com> >> Cc: George Dunlap <george.dun...@citrix.com>; xen- >> de...@lists.xenproject.org; Anthony Perard <anthony.per...@citrix.com> >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to >> Upstream >> >> On 01/04/2018 07:26 AM, Paul Durrant wrote: >>>> -Original Message- >>>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On >> Behalf >>>> Of Anthony PERARD >>>> Sent: 04 January 2018 12:52 >>>> To: Kevin Stange <ke...@steadfast.net> >>>> Cc: George Dunlap <george.dun...@citrix.com>; xen- >>>> de...@lists.xenproject.org >>>> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to >>>> Upstream >>>> >>>> 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_0001_00015853_01\3&267A616A&3&18 >>>>>>> >>>>>>> >>>> >> PCI\VEN_5853_0001_00015853_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. >>> >>> Kevin, >>> >>> I missed the original email as it went past... >>> >>> Are Xen Project PV drivers installed in the guest? And are you talking about >> a PV NIC device or an emulated device? >> >> These guests use some of the older Xen PV drivers with a PV NIC, not an >> emulated device. >> > > Ok. I was curious because the latest PV drivers contain a hack (that was > actually suggested by someone at Microsoft) to make sure that (as far as the > Windows PnP subsystem is concerned) the Xen platform device never moves once > the XENBUS driver has been installed. This is done by installing a filter > driver onto Windows' PCI bus driver that spots the platform device and > re-writes the trailing 'uniquifier' to be exactly what it was at the time of > driver installation. > So, if you update your VMs to use newer PV drivers first, then you should be > immune to the platform device moving on the bus. This is interesting and good to learn, but I had a lot of trouble in the past trying to convert existing guests to use the modern PV drivers, due to difficulties completely removing the old ones and getting Windows to adopt the new ones. The resulting mess is more work than dealing with the current problem, which is why it would be nice to be able to just massage the Windows guests to the desired configuration from outside. -- 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 ke...@steadfast.net | www.steadfast.net ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
On 01/04/2018 07:26 AM, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Anthony PERARD >> Sent: 04 January 2018 12:52 >> To: Kevin Stange <ke...@steadfast.net> >> Cc: George Dunlap <george.dun...@citrix.com>; xen- >> de...@lists.xenproject.org >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to >> Upstream >> >> 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_0001_00015853_01\3&267A616A&3&18 >>>>> >>>>> >> PCI\VEN_5853_0001_00015853_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. > > Kevin, > > I missed the original email as it went past... > > Are Xen Project PV drivers installed in the guest? And are you talking about > a PV NIC device or an emulated device? These guests use some of the older Xen PV drivers with a PV NIC, not an emulated device. -- 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 ke...@steadfast.net | www.steadfast.net ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
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_0001_00015853_01\3&267A616A&3&18
>>>>
>>>> PCI\VEN_5853_0001_00015853_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.per...@citrix.com>
>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>
>>> Signed-off-by: Anthony PERARD <anthony.per...@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
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.
--
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
ke...@steadfast.net | www.steadfast.net
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream
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_0001_00015853_01\3&267A616A&3&18
>>
>> PCI\VEN_5853_0001_00015853_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.per...@citrix.com>
> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>
> Signed-off-by: Anthony PERARD <anthony.per...@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?
--
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
ke...@steadfast.net | www.steadfast.net
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] Network and SATA Instability on Xen 4.6/4.8
On 12/21/2017 03:38 AM, Jan Beulich wrote:
> (dropping xen-users, to avoid cross posting)
>
>>>> On 20.12.17 at 18:40, <dunl...@umich.edu> wrote:
>> On Fri, Dec 8, 2017 at 9:17 PM, Kevin Stange <ke...@steadfast.net> wrote:
>>> Hi,
>>>
>>> I've been running Xen 4.4 stably for some time under kernel 4.9 in dom0
>>> on CentOS 6 and have been trying to finally move my environment up to
>>> Xen 4.6 or 4.8 using CentOS 7. Since I've built out my test server with
>>> Xen 4.6, I've been having issues where the Intel NICs begin flapping
>>> repeatedly and the SATA disk interfaces go down and will not come back
>>> up until I reboot the server. Even sending the bus rescan command
>>> doesn't bring the drives back. The issue seems to trigger based on
>>> activity, so during something like an mdraid resync is more likely to
>>> cause the issue, but it's not reproducible in a consistent amount of
>>> time, which makes it hard to tell if a particular change has definitely
>>> fixed it.
>>>
>>> This is reminiscent of a problem I had been experiencing while running
>>> kernel 3.18 and Xen 4.4 on CentOS 6, but the problem resolved itself
>>> upon upgrading to kernel 4.4 and later 4.9, so I chalked that up to
>>> something bad with PCIe management in kernel 3.18 and thought nothing
>>> more of it until now.
>>>
>>> The initial test environment where the issue occurred was kernel 4.9.58
>>> and Xen 4.6.6-7 (with security patches from CentOS). I then tried
>>> upgrading to kernel 4.9.63 and Xen 4.8.2-5, which didn't result in any
>>> improvements.
>>>
>>> I tried pcie_aspm=off on the kernel line, which has helped in the past
>>> with similar issues, but that didn't help here.
>>>
>>> I tried booting without Xen (just kernel 4.9.63) and it seems like that
>>> made the issue go away, which lead me to believe the issue only happens
>>> with hardware accessed from dom0. I dug through Xen command line
>>> options and tried booting with msi=off and that now seems to have
>>> resulted in the problem going away, or at least, the system hasn't
>>> exhibited the issue since last week. Previously, the issue would tend
>>> to manifest after less than 24 hours.
>>>
>>> My hardware is Supermicro X8DT3-F with Dual Intel Xeon E5620 CPUs.
>>>
>>> Disk issues begin with a kernel message like this followed by continuous
>>> ATA command failures:
>>>
>>> ata2.00: exception emask 0x0 sact 0x7c01 serr 0x5 action 0x6 frozen
>>>
>>> NIC issues begin with a message like:
>>>
>>> igb :04:00.1: enp4s0f1: Reset adapter unexpectedly
>>>
>>> NICs do recover almost immediately but continue to flap periodically
>>> until reboot.
>>>
>>> I don't know if this is a bug in Xen or something else at play, but I
>>> could really use some help figuring out what's going on, why msi=off
>>> seems to fix it, and if there are any better ways to resolve this.
>>
>> Jan / Andy,
>>
>> Any idea why Kevin might be seeing stability issues under 4.6 / 4.8
>> that is solved by adding 'msi=off'?
>
> Nothing I've ever heard of, and without at least full logs also very
> difficult to consider possible options. While I don't recall any
> significant bug fixes in this area since 4.8, trying with 4.10 (and
> perhaps also a more up-to-date Dom0 kernel) would certainly be
> worthwhile. With the information at hand it's not even possible
> to tell whether Xen or the Dom0 kernel is the problematic part
> here (the fact that Linux works fine natively doesn't mean much
> here, as MSI handling is quite a bit different when running on
> Xen).
I'll see if there's a build of Xen 4.10 that I can try floating around.
> What I suspect first of all is that some interrupt is not making it
> through to its handler. It may be possible to see something from
> debug key output ('M' and 'i') once the system is in that state.
Given the state gets me to a point where I can't log into the server
directly any longer, what's the best way to obtain the debug key output
at that point? I have access to IPMI with video and serial outputs.
> Just to be sure - use of an IOMMU does not affect the behavior?
I don't know how to determine "use" of IOMMU, but I did try the option
iommu=off along with msi=off and the state of the iommu option did not
seem to impact whether the issue happened, only msi=off seemed to help.
--
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
ke...@steadfast.net | www.steadfast.net
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] PCI Device Subtree Change from Traditional to Upstream
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_0001_00015853_01\3&267A616A&3&18 PCI\VEN_5853_0001_00015853_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. -- 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 ke...@steadfast.net | www.steadfast.net ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
