[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/5] Add virNodeDeviceAttach()/ReAttach()/Reset() APIs



On Wed, Feb 25, 2009 at 07:16:28PM +0000, Mark McLoughlin wrote:
> On Wed, 2009-02-25 at 17:51 +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 24, 2009 at 10:21:48PM +0000, Mark McLoughlin wrote:
> > > Before starting a guest virNodeDeviceAttach() is intended
> > > to be called on all node devices to be assigned to a guest,
> > > followed by virNodeDeviceReset() on those devices.
> > > 
> > > Once the guest has been shutdown, virNodeDeviceReset()
> > > followed by virNodeDeviceReAttach() should be called in
> > > order to make the device available to the host again.
> > > 
> > > This patch merely adds the APIs and stubs out the driver
> > > implementations.
> > 
> > While I can see a point in providing public APIs to attach/detach
> > drivers to devices - because we need this for Xen driver PCI 
> > passthrough, I'm not sure theres a compelling need for exposing
> > a reset function, because both Xen & your KVM impl are quite
> > happy doing the resets themselves.
> 
> The idea with the reset function is that calling reset is a way for the
> app to query whether this is an assignable device - e.g. if the user
> chooses a given NIC to pass through in one of the early screens in
> virt-manager, we can give a "you can't assign that device" error at that
> point rather than just having the guest fail to start up much later on.
> 
> It needs to be a separate API from dettach() because reset() may succeed
> (in future) if e.g. you dettach() all the functions on a multi-function
> device before calling reset() on one of those functions.
> 
> > I think the attach/detach functions should be in the nodedev
> > driver too, because they're not really part of the HV functionality.
> > On modern Linux kernels, both Xen & KVM (and any other users) have 
> > the same pci-stub.ko code for managed driver binding. On older Xen
> > kernels, there is the functionally equivalent pci-back.ko.
> 
> Sure, but the logic to choose between pci-stub vs. pci-back is HV
> specific, right?

No, its really kernel version depedant. On old Xen kernels it is always 
pci-back. On mainline KVM / pv_ops Xen kernels, it'll always be pci-stub
There's no need for Xen's pci-back, now the generic pci-stub exists.

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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]