Re: Bug in pci-detach (Was: Re: [Xen-devel] Re: VT-d HowTo Update)

[Simon Horman <horms@xxxxxxxxxxxx>]

On Wed, Apr 22, 2009 at 12:50:00PM +1000, Simon Horman wrote:
> Hi,
> 
> I've poked a little further into this and the problem is partly
> a missunderstanding on my part.
> 
> In the case where a function is specified in the hvm.conf in
> the form BUS:DEV:FUNC (e.g. 00:1d.0), then there is a check inside
> xm that prevents the function from subsequently being hot-unplugged.
> The check is that the vslot number is set to auto-select. And presumably
> the idea was that statically assigned devices couldn't be hot-unplugged,
> which to be honest was my initial assumption of how things work.
> 
> If, however, the function in the hvm.conf is of the form BUS:DEV:FUNC@VSLOT
> (e.g. 00:1d.00@1e) which I added recently, then the check is bypassed,
> because vslot is set to 1e not auto. This is how I was doing my tests. I
> assumed this was the behaviour for all cases, and documented it as such.
> 
> This leaves us with 3 choices:
> 
> 1. Leave the inconsistency, which seems like a bad idea.
> 2. Add a check to make sure both forms can't be hot-unplugged
>    This is more work than;
> 3. Remove the check and allow statically assigned devies to be removed.
>    This seems like a good option, and if there is consensus I can
>    fix this up into a propper patch.
> 
> diff -r 6ba4e34d21d3 tools/python/xen/xend/XendDomainInfo.py
> --- a/tools/python/xen/xend/XendDomainInfo.py Tue Apr 21 16:31:26 2009 +0100
> +++ b/tools/python/xen/xend/XendDomainInfo.py Wed Apr 22 12:42:58 2009 +1000
> @@ -1092,9 +1092,6 @@
>          if devnum >= pci_len:
>              raise VmError("Device @ vslot 0x%x doesn't exist." % (vslot))
>  
> -        if vslot == AUTO_PHP_SLOT:
> -            raise VmError("Device @ vslot 0x%x doesn't support hotplug." % 
> (vslot))
> -
>          # Check the co-assignment.
>          # To pci-detach a device D from domN, we should ensure: for each DD 
> in the
>          # list of D's co-assignment devices, DD is not assigned (to domN).

Hi,

I now believe the analysis above to be incorrect and the patch provided
not to be apropriate for 3.4.

I have posted a new fix to xen-devel as "xm: Fix hot-unplug of
statically-assigned devices".

http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00897.html

-- 
Simon Horman
  VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia
  H: www.vergenet.net/~horms/            W: www.valinux.co.jp/en


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