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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
--
best rgds,
edwin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home