From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Zhai, Edwin" <edwin.zhai@intel.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH][HVM] pass-through PCI device hotplug support
Date: Fri, 25 Jan 2008 01:40:54 +0000 [thread overview]
Message-ID: <20080125014054.GM13888@redhat.com> (raw)
In-Reply-To: <20080125013134.GG21201@edwin-srv.sh.intel.com>
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 -=|
next prev parent reply other threads:[~2008-01-25 1:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 15:52 [PATCH][HVM] pass-through PCI device hotplug support Zhai, Edwin
2008-01-24 17:57 ` Keir Fraser
2008-01-24 18:06 ` Daniel P. Berrange
2008-01-24 18:08 ` Keir Fraser
2008-01-25 1:31 ` Zhai, Edwin
2008-01-25 1:40 ` Daniel P. Berrange [this message]
2008-01-25 3:06 ` Zhai, Edwin
2008-01-25 7:41 ` Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2008-02-15 13:32 Zhai, Edwin
2008-02-15 14:36 ` Keir Fraser
2008-02-17 15:34 ` Zhai, Edwin
2008-02-17 16:43 ` Keir Fraser
2008-02-18 12:53 ` Yosuke Iwamatsu
2008-02-20 3:56 ` Zhai, Edwin
2008-02-20 4:45 ` Yosuke Iwamatsu
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=20080125014054.GM13888@redhat.com \
--to=berrange@redhat.com \
--cc=edwin.zhai@intel.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.