Kouya Shimura
2009-Mar-06 05:23 UTC
[Xen-devel] [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Hi, Using D3hot state of PCI devices in xen is not mature yet. I met domain destruction/creation troubles in some PCI cards since the PCI config registers can''t be read with D3hot state. xend.log is attached. This patch set makes the management of PCI D-states by guest optional. The default is "pci_power_mgmt=0" which disables the guest OS from managing D-states because it would be better to avoid the trouble than advantage of low power consumption. Thanks, Kouya>From xend.log:[2009-03-04 09:49:24 4356] ERROR (XendDomainInfo:2584) XendDomainInfo.destroy: domain destruction failed. Traceback (most recent call last): File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2578, in destroy do_FLR(self.domid) File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 314, in do_FLR raise VmError("pci: failed to locate device and "+ VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 found ...[snip]... [2009-03-04 10:31:24 4343] ERROR (XendDomainInfo:2445) XendDomainInfo.initDomain: exception occurred Traceback (most recent call last): File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2437, in _initDomain self._createDevices() File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2049, in _createDevices devid = self._createDevice(devclass, config) File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2016, in _createDevice return self.getDeviceController(deviceClass).createDevice(devConfig) File "/usr/lib64/python/xen/xend/server/DevController.py", line 67, in createDevice self.setupDevice(config) File "/usr/lib64/python/xen/xend/server/pciif.py", line 399, in setupDevice raise VmError("pci: failed to locate device and "+ VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 found _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Mar-06 05:26 UTC
[Xen-devel] [PATCH 1/2] tool: make management of PCI D-states by guest optional
D3hot state in some PCI devices causes the failure of domain creation/destruction. The default is "pci_power_mgmt=0" which disables the guest OS from managing D-states because it would be better to avoid the trouble than advantage of low power consumption. Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Mar-06 05:26 UTC
[Xen-devel] [PATCH 2/2] ioemu: make management of PCI D-states by guest optional
passthrough: make management of PCI D-states by guest optional Commit 8c771eb6294afc5b3754a9e3de51568d4e5986c2 enables the guest OS to program D0-D3hot states of the assigned device, however, D3hot state in some PCI devices causes the failure of domain creation/destruction. Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yuji Shimada
2009-Mar-06 07:40 UTC
[Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
On Fri, 6 Mar 2009 14:23:20 +0900 Kouya Shimura <kouya@jp.fujitsu.com> wrote:> Using D3hot state of PCI devices in xen is not mature yet. > I met domain destruction/creation troubles in some PCI cards since the > PCI config registers can''t be read with D3hot state. xend.log is attached.xend.log shows error occurred on resetting the device. I think programming the device to D0 state is needed before resetting the device. In addition to this, config register values should be saved when domain 0 starts, because in some devices config registers can''t be read with D3 hot state. To achieve this, it is good that pciback driver saves config register values when it is bound to the device, resets the device, and restores config register after resetting. Actually resetting and saving/restoring in pciback were discussed on xen-devel. But unfortunately they seem not to be under developing. Another approach is that qemu programs the device to D0 state on shutdowning of guest domain, instead of booting of guest domain. Then, xend can reset device successfully. Thanks, -- Yuji Shimada _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cui, Dexuan
2009-Mar-06 13:41 UTC
RE: [Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Yuji Shimada wrote:> On Fri, 6 Mar 2009 14:23:20 +0900 > Kouya Shimura <kouya@jp.fujitsu.com> wrote: > > >> Using D3hot state of PCI devices in xen is not mature yet. >> I met domain destruction/creation troubles in some PCI cards since >> the PCI config registers can''t be read with D3hot state. xend.log is >> attached. >> >> This patch set makes the management of PCI D-states by guest optional. >> >> The default is "pci_power_mgmt=0" which disables the guest OS from >> managing D-states because it would be better to avoid the trouble than >> advantage of low power consumption.Is this the only reason to add the guest config parameter? If yes, I don''t think it is worthwhile to have two over-200-lines patches. IMO we should fix the code in xend.> > xend.log shows error occurred on resetting the device. > I think programming the device to D0 state is needed before resetting > the device.I think so, too.> Another approach is that qemu programs the device to D0 state on > shutdowning of guest domain, instead of booting of guest domain. > Then, xend can reset device successfully.I think it''s not good to do this in ioemu. One reason is: ioemu doesn''t always know when a guest is being shut down.e.g., we may "xm destroy" a guest. xend should be a better place. Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Mar-09 00:38 UTC
RE: [Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Cui, Dexuan writes:> Yuji Shimada wrote: > > On Fri, 6 Mar 2009 14:23:20 +0900 > > Kouya Shimura <kouya@jp.fujitsu.com> wrote: > > > > >> Using D3hot state of PCI devices in xen is not mature yet. > >> I met domain destruction/creation troubles in some PCI cards since > >> the PCI config registers can''t be read with D3hot state. xend.log is > >> attached. > >> > >> This patch set makes the management of PCI D-states by guest optional. > >> > >> The default is "pci_power_mgmt=0" which disables the guest OS from > >> managing D-states because it would be better to avoid the trouble than > >> advantage of low power consumption. > Is this the only reason to add the guest config parameter? > If yes, I don''t think it is worthwhile to have two over-200-lines patches.If the answer was yes, I would have proposed to revert the patches about PCI D-states. This patch enables individual setting for each PCI passthru device and that requires many lines. Supposing a PCI device has a hardware bug, that is possible, don''t you wish to disable *only* it? Actually, Q-logic FC card which has two PCI functions looks ill. Any way, tool part of this patch is committed.> IMO we should fix the code in xend.I hope so, too. After that, turn on "pci_power_mgmt=1". Thanks, Kouya _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I was really dismayed today when I installed the latest Red Hat 5.3 and the version of Xen included is 3.1. Apparently, the only distribution with Xen 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to newer versions? I installed the released version, and it still uses Xen 3.1. Federico _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cui, Dexuan
2009-Mar-09 05:29 UTC
RE: [Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Kouya Shimura wrote:> Cui, Dexuan writes: >> Yuji Shimada wrote: >>> On Fri, 6 Mar 2009 14:23:20 +0900 >>> Kouya Shimura <kouya@jp.fujitsu.com> wrote: >>>> >>>> Using D3hot state of PCI devices in xen is not mature yet. >>>> I met domain destruction/creation troubles in some PCI cards since >>>> the PCI config registers can''t be read with D3hot state. xend.log >>>> is attached. >>>> >>>> This patch set makes the management of PCI D-states by guest >>>> optional. >>>> >>>> The default is "pci_power_mgmt=0" which disables the guest OS from >>>> managing D-states because it would be better to avoid the trouble >>>> than advantage of low power consumption. >> Is this the only reason to add the guest config parameter? >> If yes, I don''t think it is worthwhile to have two over-200-lines >> patches. > > If the answer was yes, I would have proposed to revert the patches > about PCI D-states. This patch enables individual setting for each PCI > passthru device and that requires many lines. > > Supposing a PCI device has a hardware bug, that is possible, don''t you > wish to disable *only* it? Actually, Q-logic FC card which has two > PCI functions looks ill.I agree.> > Any way, tool part of this patch is committed.Now I think it''s good. :-)> >> IMO we should fix the code in xend. > > I hope so, too. After that, turn on "pci_power_mgmt=1".Looks it''s not very easy to fix xend here. :-( e.g., I think the python error you see when guest is destroyed is caused by: xend tries to save the 256-byte pci config space of the assigned device before doing FLR, but at D3hot state, the config space is inaccessible. So, if we allow guest to program D3/D0, the current "save just before do_FLR, do_FLR, restore" in xend doesn''t work at all. We should save config space (into xenstore??) before assigning a deivce to guest, or we can save the proper values of config space into pciback. Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
This means they don''t spport VT-x and VT-d which are features that are available from later versions only? Bhaskar. -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Venefax Sent: Monday, March 09, 2009 6:16 AM To: xen-devel@lists.xensource.com Subject: [Xen-devel] Red Hat dropped XEN I was really dismayed today when I installed the latest Red Hat 5.3 and the version of Xen included is 3.1. Apparently, the only distribution with Xen 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to newer versions? I installed the released version, and it still uses Xen 3.1. Federico _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I don''t think they''d upgrade a package version in a RHEL stable release cycle -- just backport lots of patches. K. On 09/03/2009 00:46, "Venefax" <venefax@gmail.com> wrote:> I was really dismayed today when I installed the latest Red Hat 5.3 and the > version of Xen included is 3.1. Apparently, the only distribution with Xen > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to newer > versions? I installed the released version, and it still uses Xen 3.1. > Federico > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yes to VT-x, no to VT-d. -- Keir On 09/03/2009 07:41, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@lsi.com> wrote:> This means they don''t spport VT-x and VT-d which are features that are > available from later versions only? > Bhaskar. > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Venefax > Sent: Monday, March 09, 2009 6:16 AM > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] Red Hat dropped XEN > > I was really dismayed today when I installed the latest Red Hat 5.3 and the > version of Xen included is 3.1. Apparently, the only distribution with Xen > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to newer > versions? I installed the released version, and it still uses Xen 3.1. > Federico > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Mar 08, 2009 at 08:46:22PM -0400, Venefax wrote:> I was really dismayed today when I installed the latest Red Hat 5.3 and the > version of Xen included is 3.1. Apparently, the only distribution with Xen > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to newer > versions? I installed the released version, and it still uses Xen 3.1.Things are not quite that simple. The RHEL-5 userspace tools are mostly on a 3.0.3 base, while the hypervisor and kernel are on a 3.1.0 base. The base versions are typically not upgraded during the lifetime of a major RHEL release series. That said, we do have a large number of carefully backported features & patches from newer versions, eg to add support for NPT/EPT, improved HVM support, hugepage support, and much more besides. So just comparing version numbers won''t give you a true picture of Xen features available in RHEL-5. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I was trying to use some of the command set, like "xm new -F" etc., and it did not work, so I did checked and the xm options are limited, compared to SLES 10 SP2 or the Beta SLES 11. It is an inferior product. For example, what I typically do is this: Create a paravirtualized domU Xm list --long domname > domname.sxp Edit domname.sxp and add (cpus 2-15) Xm new -F domname.sxp The question is: how do you achieve that with RHEL 5.3? I don''t want my Dumu''s to use all the CPU''s, since I restrict Dom0 to CPU''s 0-1. Is there a way, at all? Federico -----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Monday, March 09, 2009 6:13 AM To: Venefax Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Red Hat dropped XEN On Sun, Mar 08, 2009 at 08:46:22PM -0400, Venefax wrote:> I was really dismayed today when I installed the latest Red Hat 5.3 andthe> version of Xen included is 3.1. Apparently, the only distribution with Xen > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen tonewer> versions? I installed the released version, and it still uses Xen 3.1.Things are not quite that simple. The RHEL-5 userspace tools are mostly on a 3.0.3 base, while the hypervisor and kernel are on a 3.1.0 base. The base versions are typically not upgraded during the lifetime of a major RHEL release series. That said, we do have a large number of carefully backported features & patches from newer versions, eg to add support for NPT/EPT, improved HVM support, hugepage support, and much more besides. So just comparing version numbers won''t give you a true picture of Xen features available in RHEL-5. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
You could try upgrading to 3.3.1 from http://www.gitco.de/repo/ On Mon, 2009-03-09 at 06:22 -0400, Venefax wrote:> I was trying to use some of the command set, like "xm new -F" etc., and it > did not work, so I did checked and the xm options are limited, compared to > SLES 10 SP2 or the Beta SLES 11. It is an inferior product. For example, > what I typically do is this: > Create a paravirtualized domU > Xm list --long domname > domname.sxp > Edit domname.sxp and add (cpus 2-15) > Xm new -F domname.sxp > > The question is: how do you achieve that with RHEL 5.3? I don''t want my > Dumu''s to use all the CPU''s, since I restrict Dom0 to CPU''s 0-1. Is there a > way, at all? > Federico > > > -----Original Message----- > From: Daniel P. Berrange [mailto:berrange@redhat.com] > Sent: Monday, March 09, 2009 6:13 AM > To: Venefax > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Red Hat dropped XEN > > On Sun, Mar 08, 2009 at 08:46:22PM -0400, Venefax wrote: > > I was really dismayed today when I installed the latest Red Hat 5.3 and > the > > version of Xen included is 3.1. Apparently, the only distribution with Xen > > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to > newer > > versions? I installed the released version, and it still uses Xen 3.1. > > Things are not quite that simple. The RHEL-5 userspace tools are mostly on > a 3.0.3 base, while the hypervisor and kernel are on a 3.1.0 base. The base > versions are typically not upgraded during the lifetime of a major RHEL > release series. That said, we do have a large number of carefully backported > > features & patches from newer versions, eg to add support for NPT/EPT, > improved HVM support, hugepage support, and much more besides. So just > comparing version numbers won''t give you a true picture of Xen features > available in RHEL-5. > > Regards, > Daniel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Are there any instructions as how to do that? Or it is just a case of downloading the RPM''s and installing them? Federico -----Original Message----- From: Mike Brady [mailto:mike.brady@devnull.net.nz] Sent: Monday, March 09, 2009 12:41 PM To: Venefax Cc: ''Daniel P. Berrange''; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] Red Hat dropped XEN You could try upgrading to 3.3.1 from http://www.gitco.de/repo/ On Mon, 2009-03-09 at 06:22 -0400, Venefax wrote:> I was trying to use some of the command set, like "xm new -F" etc., and it > did not work, so I did checked and the xm options are limited, compared to > SLES 10 SP2 or the Beta SLES 11. It is an inferior product. For example, > what I typically do is this: > Create a paravirtualized domU > Xm list --long domname > domname.sxp > Edit domname.sxp and add (cpus 2-15) > Xm new -F domname.sxp > > The question is: how do you achieve that with RHEL 5.3? I don''t want my > Dumu''s to use all the CPU''s, since I restrict Dom0 to CPU''s 0-1. Is therea> way, at all? > Federico > > > -----Original Message----- > From: Daniel P. Berrange [mailto:berrange@redhat.com] > Sent: Monday, March 09, 2009 6:13 AM > To: Venefax > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Red Hat dropped XEN > > On Sun, Mar 08, 2009 at 08:46:22PM -0400, Venefax wrote: > > I was really dismayed today when I installed the latest Red Hat 5.3 and > the > > version of Xen included is 3.1. Apparently, the only distribution withXen> > 3.3 is Suse. Am I reading here that Red Hat will never upgrade Xen to > newer > > versions? I installed the released version, and it still uses Xen 3.1. > > Things are not quite that simple. The RHEL-5 userspace tools are mostly on> a 3.0.3 base, while the hypervisor and kernel are on a 3.1.0 base. Thebase> versions are typically not upgraded during the lifetime of a major RHEL > release series. That said, we do have a large number of carefullybackported> > features & patches from newer versions, eg to add support for NPT/EPT, > improved HVM support, hugepage support, and much more besides. So just > comparing version numbers won''t give you a true picture of Xen features > available in RHEL-5. > > Regards, > Daniel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yuji Shimada
2009-Mar-11 08:16 UTC
[Xen-devel] Re: [PATCH 2/2] ioemu: make management of PCI D-states by guest optional
On Fri, 6 Mar 2009 14:26:37 +0900 Kouya Shimura <kouya@jp.fujitsu.com> wrote:> +/* read Power Management Control/Status register */ > +static int pt_pmcsr_reg_read(struct pt_dev *ptdev, > + struct pt_reg_tbl *cfg_entry, > + uint16_t *value, uint16_t valid_mask) > +{ > + struct pt_reg_info_tbl *reg = cfg_entry->reg; > + uint16_t valid_emu_mask = reg->emu_mask; > + > + if (!ptdev->power_mgmt) > + valid_emu_mask |= PCI_PM_CTRL_STATE_MASK;(snip)> @@ -3082,6 +3113,24 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev, > struct pt_pm_info *pm_state = ptdev->pm_state; > uint16_t read_val = 0; > > + if (!ptdev->power_mgmt) { > + uint16_t emu_mask = > + PCI_PM_CTRL_PME_STATUS | PCI_PM_CTRL_DATA_SCALE_MASK | > + PCI_PM_CTRL_PME_ENABLE | > + PCI_PM_CTRL_DATA_SEL_MASK | PCI_PM_CTRL_STATE_MASK; > + uint16_t ro_mask = PCI_PM_CTRL_DATA_SCALE_MASK;Hi, Why are Data_Scale field and Data_Select field emulated? I think we can pass-through them as follows. On the other hand, No_Soft_Reset field needs to be emulated and fixed to 1. The reason is PowerState field is emulated, that means guest software can change power state, but actual power state of device is not changed. So internal reset never occurs. As a result, the code will be as the following. read: valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET; write: uint16_t emu_mask = reg->emu_mask | PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET; uint16_t ro_mask = reg->ro_mask; Thanks, -- Yuji Shimada _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Mar-11 08:57 UTC
Re: [Xen-devel] Re: [PATCH 2/2] ioemu: make management of PCI D-states by guest optional
Yuji Shimada writes:> Why are Data_Scale field and Data_Select field emulated?No reason, I intended that emu_mask and ro_mask become the same as before your PCI D-state patch.> I think we can pass-through them as follows. > > On the other hand, No_Soft_Reset field needs to be emulated and fixed > to 1. The reason is PowerState field is emulated, that means guest > software can change power state, but actual power state of device is > not changed. So internal reset never occurs. > > As a result, the code will be as the following. > > read: > valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | > PCI_PM_CTRL_NO_SOFT_RESET; > > write: > uint16_t emu_mask = reg->emu_mask | PCI_PM_CTRL_STATE_MASK | > PCI_PM_CTRL_NO_SOFT_RESET; > uint16_t ro_mask = reg->ro_mask;Thank you for pointing out. I''ll fix it. Thanks, Kouya _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Mar-12 06:05 UTC
[Xen-devel] [PATCH v2 2/2] ioemu: make management of PCI D-states by guest optional
This is an updated patch per Shimada-san''s advice.
Commit 8c771eb6294afc5b3754a9e3de51568d4e5986c2 enables the guest OS
to program D0-D3hot states of the assigned device, however,
D3hot state in some PCI devices causes the failure of domain
creation/destruction.
With this patch, we can configure a guest to manage the PCI D-states
or not for each PCI passthru device.
A corresponding change is committed to xen-unstable.hg.
chageset: 19279:ec671455fb05ca6714deeaca78aacb1026ca4752
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Yuji Shimada
2009-Apr-23 05:48 UTC
[Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
On Fri, 6 Mar 2009 14:23:20 +0900 Kouya Shimura <kouya@jp.fujitsu.com> wrote:> Hi, > > Using D3hot state of PCI devices in xen is not mature yet. > I met domain destruction/creation troubles in some PCI cards since the > PCI config registers can''t be read with D3hot state. xend.log is attached. > > This patch set makes the management of PCI D-states by guest optional. > > The default is "pci_power_mgmt=0" which disables the guest OS from > managing D-states because it would be better to avoid the trouble than > advantage of low power consumption. > > Thanks, > Kouya > > From xend.log: > > [2009-03-04 09:49:24 4356] ERROR (XendDomainInfo:2584) XendDomainInfo.destroy: domain destruction failed. > Traceback (most recent call last): > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2578, in destroy > do_FLR(self.domid) > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 314, in do_FLR > raise VmError("pci: failed to locate device and "+ > VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 found > ...[snip]... > [2009-03-04 10:31:24 4343] ERROR (XendDomainInfo:2445) XendDomainInfo.initDomain: exception occurred > Traceback (most recent call last): > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2437, in _initDomain > self._createDevices() > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2049, in _createDevices > devid = self._createDevice(devclass, config) > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2016, in _createDevice > return self.getDeviceController(deviceClass).createDevice(devConfig) > File "/usr/lib64/python/xen/xend/server/DevController.py", line 67, in createDevice > self.setupDevice(config) > File "/usr/lib64/python/xen/xend/server/pciif.py", line 399, in setupDevice > raise VmError("pci: failed to locate device and "+ > VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 foundHi, Shimura-san In my environment, I can''t draw above error. So could you test the following patches? http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00829.html I think your D-state problem is resolved with these patches. Thanks, -- Yuji Shimada _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kouya Shimura
2009-Apr-23 07:08 UTC
[Xen-devel] Re: [PATCH 0/2] passthrough: make management of PCI D-states by guest optional
Hi, I tried your patches. Acutually, error messages in xend.log have gone. So, the problem that PCI config can''t be read correctly, is resolved. However, my D-state problem is not resolved yet. In a PCI HBA card, qemu-dm.log shows: check_power_state: Error: Failed to change power state. [00:03.0][requested sta te:3][current state:0] Probably this is a hardware problem. After that, an HVM guest can''t boot up from its disk again. Thus, for the present, I''ll still set ''pci_power_mgmt=0''. Thanks, Kouya Yuji Shimada writes:> On Fri, 6 Mar 2009 14:23:20 +0900 > Kouya Shimura <kouya@jp.fujitsu.com> wrote: > > > Hi, > > > > Using D3hot state of PCI devices in xen is not mature yet. > > I met domain destruction/creation troubles in some PCI cards since the > > PCI config registers can''t be read with D3hot state. xend.log is attached. > > > > This patch set makes the management of PCI D-states by guest optional. > > > > The default is "pci_power_mgmt=0" which disables the guest OS from > > managing D-states because it would be better to avoid the trouble than > > advantage of low power consumption. > > > > Thanks, > > Kouya > > > > From xend.log: > > > > [2009-03-04 09:49:24 4356] ERROR (XendDomainInfo:2584) XendDomainInfo.destroy: domain destruction failed. > > Traceback (most recent call last): > > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2578, in destroy > > do_FLR(self.domid) > > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 314, in do_FLR > > raise VmError("pci: failed to locate device and "+ > > VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 found > > ...[snip]... > > [2009-03-04 10:31:24 4343] ERROR (XendDomainInfo:2445) XendDomainInfo.initDomain: exception occurred > > Traceback (most recent call last): > > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2437, in _initDomain > > self._createDevices() > > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2049, in _createDevices > > devid = self._createDevice(devclass, config) > > File "/usr/lib64/python/xen/xend/XendDomainInfo.py", line 2016, in _createDevice > > return self.getDeviceController(deviceClass).createDevice(devConfig) > > File "/usr/lib64/python/xen/xend/server/DevController.py", line 67, in createDevice > > self.setupDevice(config) > > File "/usr/lib64/python/xen/xend/server/pciif.py", line 399, in setupDevice > > raise VmError("pci: failed to locate device and "+ > > VmError: pci: failed to locate device and parse it''s resources - ord() expected a character, but string of length 0 found > > Hi, Shimura-san > > In my environment, I can''t draw above error. > > So could you test the following patches? > > http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00829.html > > I think your D-state problem is resolved with these patches. > > Thanks, > -- > Yuji Shimada_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel