Xen devel - Jan 2008 - [PATCH][HVM] pass-through PCI device hotplug support

All,

This patch enables HVM guest VT-d device hotplug via a simple ACPI hotplug 
device model. Pls. have a look.

On VT-d side, it''s very useful as you can dynamically assign VT-d
device to a
guest as long as it support ACPI hotplug(Linux 2.6, 2000, 2003, XP... pass the 
test).

* Usage is very simple.
Three new commands are added:
"xm dpci-list domid" show the current assigned vtd device, like:
ID  domain   bus   slot   func
0      0x0  0x02   0x00    0x0

"xm dpci-remove" hot remove the specified vtd device by the ID, like:
xm dpci-remove EdwinHVMDomainVtd 0

"xm dpci-insert" hot add a new vtd device, like
''03:00.0'':
xm dpci-insert EdwinHVMDomainVtd 3 0 0

* Currently only 2 virtual pci slots are made as being capable of hotplug, so 
more than 2 vtd dev can''t be hotplugged, but we can easily extend it in
future.

* I reuse the pci PV driver configuration but untouch the code path since there 
may be HVM pci PV driver in future. I''m not sure if the python changes
are okay,
maybe you guys have some good idea.
 
Thanks,

-- 
best rgds,
edwin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Please add more comments to your DSDT changes so it''s clear what the
changes
are actually for. A paragraph or two distributed around your changes would
be good, including references to the ACPI specification document where that
is useful.

Apart from that I expect the patch is fine. You can send the DSDT comments
as an incremental patch on top of this one.

 -- Keir


On 23/1/08 15:52, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:
> All,
> 
> This patch enables HVM guest VT-d device hotplug via a simple ACPI hotplug
> device model. Pls. have a look.
> 
> On VT-d side, it''s very useful as you can dynamically assign VT-d
device to a
> guest as long as it support ACPI hotplug(Linux 2.6, 2000, 2003, XP... pass
the
> test).
> 
> * Usage is very simple.
> Three new commands are added:
> "xm dpci-list domid" show the current assigned vtd device, like:
> ID  domain   bus   slot   func
> 0      0x0  0x02   0x00    0x0
> 
> "xm dpci-remove" hot remove the specified vtd device by the ID,
like:
> xm dpci-remove EdwinHVMDomainVtd 0
> 
> "xm dpci-insert" hot add a new vtd device, like
''03:00.0'':
> xm dpci-insert EdwinHVMDomainVtd 3 0 0
> 
> * Currently only 2 virtual pci slots are made as being capable of hotplug,
so
> more than 2 vtd dev can''t be hotplugged, but we can easily extend
it in
> future.
> 
> * I reuse the pci PV driver configuration but untouch the code path since
> there 
> may be HVM pci PV driver in future. I''m not sure if the python
changes are
> okay, 
> maybe you guys have some good idea.
>  
> Thanks,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Jan 23, 2008 at 11:52:09PM +0800, Zhai, Edwin
wrote:
> All,
> 
> This patch enables HVM guest VT-d device hotplug via a simple ACPI hotplug 
> device model. Pls. have a look.
> 
> On VT-d side, it''s very useful as you can dynamically assign VT-d
device to a
> guest as long as it support ACPI hotplug(Linux 2.6, 2000, 2003, XP... pass
the
> test).
> 
> * Usage is very simple.
> Three new commands are added:
> "xm dpci-list domid" show the current assigned vtd device, like:
> ID  domain   bus   slot   func
> 0      0x0  0x02   0x00    0x0
> 
> "xm dpci-remove" hot remove the specified vtd device by the ID,
like:
> xm dpci-remove EdwinHVMDomainVtd 0
> 
> "xm dpci-insert" hot add a new vtd device, like
''03:00.0'':
> xm dpci-insert EdwinHVMDomainVtd 3 0 0
IMHO we shouldn''t have a ''d'' on the front of the
command names. VT-d is a
vendor specific implementation whose nomenculture doesn''t need to be
exposed
to users. In addition the existing block & network hotplug commands use
''attach'' and ''detach'' for their command
names. So for sake of consistency
I''d recommend command names of:

  pci-list
  pci-attach
  pci-detach

I think it is useful to use the same unique naming & data for both attach
and
detach operations. So if we use a (bus,slot,func) triple for attachment, I
think we should use the same (bus,slot,func) triple for detachment too,
rather than having to make apps / users lookup the dynamically-allocated
''ID'' value for the device.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   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

On 24/1/08 18:06, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
> IMHO we shouldn''t have a ''d'' on the front of the
command names. VT-d is a
> vendor specific implementation whose nomenculture doesn''t need to
be exposed
> to users. In addition the existing block & network hotplug commands use
> ''attach'' and ''detach'' for their command
names. So for sake of consistency
> I''d recommend command names of:
> 
>   pci-list
>   pci-attach
>   pci-detach
> 
> I think it is useful to use the same unique naming & data for both
attach and
> detach operations. So if we use a (bus,slot,func) triple for attachment, I
> think we should use the same (bus,slot,func) triple for detachment too,
> rather than having to make apps / users lookup the dynamically-allocated
> ''ID'' value for the device.
Seconded.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Jan 24, 2008 at 06:06:56PM +0000, Daniel P. Berrange
wrote:
> > 
> > "xm dpci-remove" hot remove the specified vtd device by the
ID, like:
> > xm dpci-remove EdwinHVMDomainVtd 0
> > 
> > "xm dpci-insert" hot add a new vtd device, like
''03:00.0'':
> > xm dpci-insert EdwinHVMDomainVtd 3 0 0
> 
> IMHO we shouldn''t have a ''d'' on the front of the
command names. VT-d is a
> vendor specific implementation whose nomenculture doesn''t need to
be exposed
''d'' means directly assigned device, which is generic including
VT-d and other
pass-through device..

Anyway, it''s not so important.
> to users. In addition the existing block & network hotplug commands use
> ''attach'' and ''detach'' for their command
names. So for sake of consistency
> I''d recommend command names of:
> 
>   pci-list
>   pci-attach
>   pci-detach
I had the same idea at the beginning, but change mind due to some concerns:

xxx-attach/detach are used for _PV_ driver, but dpci is not the case.
If pci PV driver support hotplug in future, we get a complicated code path to 
handle both PV and dpci''s hotplug.

So do we have plan to support PCI PV driver hotplug? If no, we can use 
pci-attach/detach.
> 
> I think it is useful to use the same unique naming & data for both
attach and
> detach operations. So if we use a (bus,slot,func) triple for attachment, I
> think we should use the same (bus,slot,func) triple for detachment too,
> rather than having to make apps / users lookup the dynamically-allocated
> ''ID'' value for the device.
yes, dynamical ID is not easily for use.
How about using some fixed ''ID'' for hot remove, just like
vbd/vnif(they also use
different naming&data for attach/detach)?

> 
> Regards,
> Dan.
> -- 
> |=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496
-=|
> |=-           Perl modules: http://search.cpan.org/~danberr/             
-=|
> |=-               Projects: http://freshmeat.net/~danielpb/              
-=|
> |=-  GnuPG: 7D3B9505   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
> 
-- 
best rgds,
edwin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Jan 25, 2008 at 09:31:34AM +0800, Zhai, Edwin
wrote:
> On Thu, Jan 24, 2008 at 06:06:56PM +0000, Daniel P. Berrange wrote:
> > > 
> > > "xm dpci-remove" hot remove the specified vtd device by
the ID, like:
> > > xm dpci-remove EdwinHVMDomainVtd 0
> > > 
> > > "xm dpci-insert" hot add a new vtd device, like
''03:00.0'':
> > > xm dpci-insert EdwinHVMDomainVtd 3 0 0
> > 
> > IMHO we shouldn''t have a ''d'' on the front
of the command names. VT-d is a
> > vendor specific implementation whose nomenculture doesn''t
need to be exposed
> 
> ''d'' means directly assigned device, which is generic
including VT-d and other
> pass-through device..
> 
> Anyway, it''s not so important.
> 
> > to users. In addition the existing block & network hotplug
commands use
> > ''attach'' and ''detach'' for their
command names. So for sake of consistency
> > I''d recommend command names of:
> > 
> >   pci-list
> >   pci-attach
> >   pci-detach
> 
> I had the same idea at the beginning, but change mind due to some concerns:
> 
> xxx-attach/detach are used for _PV_ driver, but dpci is not the case.
> If pci PV driver support hotplug in future, we get a complicated code path
to
> handle both PV and dpci''s hotplug.
I don''t buy that argument. You can still just have completely separate
codepaths inside XenD if you really need to - just switch on different
impls in the main RPC dispatcher...

 def pci_attach()
    if dom.is_hvm():
       pci_attach_hvm()
    else
       pci_attach_pv()

Every part of Xen where we expose the user to a difference between HVM
vs PV is a point of pain. We should ensure that use of HVM & PV is as 
near as possible, identical from a user''s view.
> So do we have plan to support PCI PV driver hotplug? If no, we can use 
> pci-attach/detach.
>From the user''s point of view they are attaching & detaching
PCI devices,
and they should not have to use separate commands to do the same operation
for PV vs HVM.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   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

On Fri, Jan 25, 2008 at 01:40:54AM +0000, Daniel P. Berrange
wrote:
> > 
> > I had the same idea at the beginning, but change mind due to some
concerns:
> > 
> > xxx-attach/detach are used for _PV_ driver, but dpci is not the case.
> > If pci PV driver support hotplug in future, we get a complicated code
path to
> > handle both PV and dpci''s hotplug.
> 
> I don''t buy that argument. You can still just have completely
separate
> codepaths inside XenD if you really need to - just switch on different
> impls in the main RPC dispatcher...
> 
>  def pci_attach()
>     if dom.is_hvm():
>        pci_attach_hvm()
>     else
>        pci_attach_pv()
> 
> Every part of Xen where we expose the user to a difference between HVM
> vs PV is a point of pain. We should ensure that use of HVM & PV is as 
> near as possible, identical from a user''s view.
If we support PV driver in HVM guest with hotplug, the code path become more 
complicated:(

Anyway it''s a trade off. I can change to pci_attach/detach for a simple
user
interface with complicated implementation.

> 
> > So do we have plan to support PCI PV driver hotplug? If no, we can use
> > pci-attach/detach.
> 
> >From the user''s point of view they are attaching &
detaching PCI devices,
> and they should not have to use separate commands to do the same operation
> for PV vs HVM.
> 
> Regards,
> Dan.
> -- 
> |=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496
-=|
> |=-           Perl modules: http://search.cpan.org/~danberr/             
-=|
> |=-               Projects: http://freshmeat.net/~danielpb/              
-=|
> |=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 
-=|
> 
-- 
best rgds,
edwin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 25/1/08 01:31, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:
>> to users. In addition the existing block & network hotplug commands
use
>> ''attach'' and ''detach'' for their
command names. So for sake of consistency
>> I''d recommend command names of:
>> 
>>   pci-list
>>   pci-attach
>>   pci-detach
> 
> I had the same idea at the beginning, but change mind due to some concerns:
> 
> xxx-attach/detach are used for _PV_ driver, but dpci is not the case.
> If pci PV driver support hotplug in future, we get a complicated code path
to
> handle both PV and dpci''s hotplug.
> 
> So do we have plan to support PCI PV driver hotplug? If no, we can use
> pci-attach/detach.
That''s a hideously bad argument.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir,

This patch is the new version against 17051 to enable HVM guest VT-d device 
hotplug.


** Currently only 2 virtual pci slots(6~7) are made as being capable of hotplug,
so more than 2 vtd dev can''t be hotplugged, but we can easily extend it
in
future.

Three new commands are added:
"xm pci-list domid" show the current assigned vtd device, like:
VSlt  domain   bus   slot   func
0x6      0x0  0x02   0x00    0x0

"xm pci-detach" hot remove the specified vtd device by the virtual
slot, like:
xm pci-detach EdwinHVMDomainVtd 6

"xm pci-attach DomainID dom bus dev func [vslot]" hot add a new vtd
device in
the vslot. If no vslot specified, a free slot will be picked up. e.g. to insert 
''0000:03:00.0'':
xm pci-attach EdwinHVMDomainVtd 0 3 0 0

** guest pci hotplug
linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus options=> PCI hotplug
=>
ACPI PCI hotplug driver)
windows: 2000/xp/2003/vista are all okay


Thanks a lot.

-- 
best rgds,
edwin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 15/2/08 13:32, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:
> This patch is the new version against 17051 to enable HVM guest VT-d device
> hotplug.
> 
> ** Currently only 2 virtual pci slots(6~7) are made as being capable of
> hotplug, 
> so more than 2 vtd dev can''t be hotplugged, but we can easily
extend it in
> future.
Now applied, but perhaps too hastily. I found it broke the
!CONFIG_PASSTHROUGH build and in fixing that I noticed that you dumped code
in a bunch of random places in qemu. Perhaps all passthrough stuff should be
gathered in one place? Alternatively at least the device model changes (in
piix4acpi.c) should be decoupled a bit from the backend logic in
passthrough.c, so the former can cleanly build without the latter. I also
killed pt_uninit() because I couldn''t even find where pci_cleanup() was
defined. No passthrough function should be in vl.c: I #ifdef''ed in the
for
now but the functions should probably be moved. And you did a big dump of
random crap into vl.h.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir,
c/s 17056 also works for AMD-IOMMU, attached patch introduces a new
vendor independent interface for device detachment. 
Thanks,

Wei
-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy 

On Fri, 2008-02-15 at 14:36 +0000, Keir Fraser wrote:
> On 15/2/08 13:32, "Zhai, Edwin" <edwin.zhai@intel.com>
wrote:
> 
> > This patch is the new version against 17051 to enable HVM guest VT-d
device
> > hotplug.
> > 
> > ** Currently only 2 virtual pci slots(6~7) are made as being capable
of
> > hotplug, 
> > so more than 2 vtd dev can''t be hotplugged, but we can easily
extend it in
> > future.
> 
> Now applied, but perhaps too hastily. I found it broke the
> !CONFIG_PASSTHROUGH build and in fixing that I noticed that you dumped code
> in a bunch of random places in qemu. Perhaps all passthrough stuff should
be
> gathered in one place? Alternatively at least the device model changes (in
> piix4acpi.c) should be decoupled a bit from the backend logic in
> passthrough.c, so the former can cleanly build without the latter. I also
> killed pt_uninit() because I couldn''t even find where
pci_cleanup() was
> defined. No passthrough function should be in vl.c: I #ifdef''ed in
the for
> now but the functions should probably be moved. And you did a big dump of
> random crap into vl.h.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> 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

Adding a signed off line.

Signed-off-by: Wei Wang <wei.wang2@amd.com>
--
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

On Fri, 2008-02-15 at 18:19 +0100, Wei Wang2 wrote:
> Keir,
> c/s 17056 also works for AMD-IOMMU, attached patch introduces a new
> vendor independent interface for device detachment. 
> Thanks,
> 
> Wei
> _______________________________________________
> 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 Fri, Feb 15, 2008 at 02:36:49PM +0000, Keir Fraser
wrote:
> On 15/2/08 13:32, "Zhai, Edwin" <edwin.zhai@intel.com>
wrote:
> 
> > This patch is the new version against 17051 to enable HVM guest VT-d
device
> > hotplug.
> > 
> > ** Currently only 2 virtual pci slots(6~7) are made as being capable
of
> > hotplug, 
> > so more than 2 vtd dev can''t be hotplugged, but we can easily
extend it in
> > future.
> 
> Now applied, but perhaps too hastily. I found it broke the
> !CONFIG_PASSTHROUGH build and in fixing that I noticed that you dumped code
I assumed CONFIG_PASSTHROUGH is always on by default:(
So maybe need more #ifdef.
> in a bunch of random places in qemu. Perhaps all passthrough stuff should
be
> gathered in one place? Alternatively at least the device model changes (in
> piix4acpi.c) should be decoupled a bit from the backend logic in
Agree with you. passthrough.c manage all the pass-through device info, while
piix4acpi.c manage GPE & hotplug controller and call into passthough.c in
some
condition(say a IO indicating hot removal arrive). 

So at least one pair of passthrough function should be in the piix4acpi and 
ifdef''ed, but we can move all the xenstore logic to it as you said.

> passthrough.c, so the former can cleanly build without the latter. I also
> killed pt_uninit() because I couldn''t even find where
pci_cleanup() was
pci_cleanup() is in the libpci, which should be called for clean up in theory.  
But things goes well without it.
> defined. No passthrough function should be in vl.c: I #ifdef''ed in
the for
Our plan is making this hotplug generic besides passthough device, even for 
virtual PCI device on native QEMU. So leaving do_pci_add/del in vl.c should be 
okay like do_usb_xxx.
> now but the functions should probably be moved. And you did a big dump of
> random crap into vl.h.
> 
>  -- Keir
> 
> 
-- 
best rgds,
edwin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 17/2/08 15:34, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:
>> passthrough.c, so the former can cleanly build without the latter. I
also
>> killed pt_uninit() because I couldn''t even find where
pci_cleanup() was
> 
> pci_cleanup() is in the libpci, which should be called for clean up in
theory.
> But things goes well without it.
Well, you can add it back in then.
>> defined. No passthrough function should be in vl.c: I
#ifdef''ed in the for
> 
> Our plan is making this hotplug generic besides passthough device, even for
> virtual PCI device on native QEMU. So leaving do_pci_add/del in vl.c should
be
> okay like do_usb_xxx.
Isn''t there a generic pci source file where they might more sensibly
belong?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

Just for your information,
I have been working on pass-through PCI device hotplug for PV domains,
and now pci-attach/detach for PV domains worked successfully.
I think I can submit an RFC patch in a few days.

Thanks,
-----------------
Yosuke Iwamatsu
  NEC Corporation


Zhai, Edwin wrote:
> Keir,
> 
> This patch is the new version against 17051 to enable HVM guest VT-d device
> hotplug.
> 
> 
> ** Currently only 2 virtual pci slots(6~7) are made as being capable of
hotplug,
> so more than 2 vtd dev can''t be hotplugged, but we can easily
extend it in
> future.
> 
> Three new commands are added:
> "xm pci-list domid" show the current assigned vtd device, like:
> VSlt  domain   bus   slot   func
> 0x6      0x0  0x02   0x00    0x0
> 
> "xm pci-detach" hot remove the specified vtd device by the
virtual slot, like:
> xm pci-detach EdwinHVMDomainVtd 6
> 
> "xm pci-attach DomainID dom bus dev func [vslot]" hot add a new
vtd device in
> the vslot. If no vslot specified, a free slot will be picked up. e.g. to
insert
> ''0000:03:00.0'':
> xm pci-attach EdwinHVMDomainVtd 0 3 0 0
> 
> ** guest pci hotplug
> linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus options=> PCI
hotplug =>
> ACPI PCI hotplug driver)
> windows: 2000/xp/2003/vista are all okay
> 
> 
> Thanks a lot.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Thanks for you info.

Did you change the PCI dev config in xend, which is not friendly to hotplug?
(only one dev node for all pass-through devices)

Do you have a HVM PV driver for pass-through device?


Thanks,


On Mon, Feb 18, 2008 at 09:53:22PM +0900, Yosuke Iwamatsu
wrote:
> Hi,
> 
> Just for your information,
> I have been working on pass-through PCI device hotplug for PV domains,
> and now pci-attach/detach for PV domains worked successfully.
> I think I can submit an RFC patch in a few days.
> 
> Thanks,
> -----------------
> Yosuke Iwamatsu
>   NEC Corporation
> 
> 
> Zhai, Edwin wrote:
> > Keir,
> > 
> > This patch is the new version against 17051 to enable HVM guest VT-d
device
> > hotplug.
> > 
> > 
> > ** Currently only 2 virtual pci slots(6~7) are made as being capable
of hotplug,
> > so more than 2 vtd dev can''t be hotplugged, but we can easily
extend it in
> > future.
> > 
> > Three new commands are added:
> > "xm pci-list domid" show the current assigned vtd device,
like:
> > VSlt  domain   bus   slot   func
> > 0x6      0x0  0x02   0x00    0x0
> > 
> > "xm pci-detach" hot remove the specified vtd device by the
virtual slot, like:
> > xm pci-detach EdwinHVMDomainVtd 6
> > 
> > "xm pci-attach DomainID dom bus dev func [vslot]" hot add a
new vtd device in
> > the vslot. If no vslot specified, a free slot will be picked up. e.g.
to insert
> > ''0000:03:00.0'':
> > xm pci-attach EdwinHVMDomainVtd 0 3 0 0
> > 
> > ** guest pci hotplug
> > linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus options=>
PCI hotplug =>
> > ACPI PCI hotplug driver)
> > windows: 2000/xp/2003/vista are all okay
> > 
> > 
> > Thanks a lot.
> > 
> > 
> > 
> >
------------------------------------------------------------------------
> > 
> > _______________________________________________
> > 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
> 
-- 
best rgds,
edwin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Zhai, Edwin wrote:
> Thanks for you info.
> 
> Did you change the PCI dev config in xend, which is not friendly to
hotplug?
> (only one dev node for all pass-through devices)
No, I left it as it was.
> 
> Do you have a HVM PV driver for pass-through device?
No, I included hotplug handling methods in pcifront driver
which work only on PV linux.

Thanks,
----------
     Yosuke
> 
> 
> Thanks,
> 
> 
> On Mon, Feb 18, 2008 at 09:53:22PM +0900, Yosuke Iwamatsu wrote:
>> Hi,
>>
>> Just for your information,
>> I have been working on pass-through PCI device hotplug for PV domains,
>> and now pci-attach/detach for PV domains worked successfully.
>> I think I can submit an RFC patch in a few days.
>>
>> Thanks,
>> -----------------
>> Yosuke Iwamatsu
>>   NEC Corporation
>>
>>
>> Zhai, Edwin wrote:
>>> Keir,
>>>
>>> This patch is the new version against 17051 to enable HVM guest
VT-d device
>>> hotplug.
>>>
>>>
>>> ** Currently only 2 virtual pci slots(6~7) are made as being
capable of hotplug,
>>> so more than 2 vtd dev can''t be hotplugged, but we can
easily extend it in
>>> future.
>>>
>>> Three new commands are added:
>>> "xm pci-list domid" show the current assigned vtd device,
like:
>>> VSlt  domain   bus   slot   func
>>> 0x6      0x0  0x02   0x00    0x0
>>>
>>> "xm pci-detach" hot remove the specified vtd device by
the virtual slot, like:
>>> xm pci-detach EdwinHVMDomainVtd 6
>>>
>>> "xm pci-attach DomainID dom bus dev func [vslot]" hot add
a new vtd device in
>>> the vslot. If no vslot specified, a free slot will be picked up.
e.g. to insert
>>> ''0000:03:00.0'':
>>> xm pci-attach EdwinHVMDomainVtd 0 3 0 0
>>>
>>> ** guest pci hotplug
>>> linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus
options=> PCI hotplug =>
>>> ACPI PCI hotplug driver)
>>> windows: 2000/xp/2003/vista are all okay
>>>
>>>
>>> Thanks a lot.
>>>
>>>
>>>
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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