Alex - I am rejecting these 2 patches.

For patch 1/2, I started with yours and found a couple of problems, but then I 
got into the spirit and did a buinch more cleaning up. My patch to follow.

For patch 2/2, the INTX stuff, I don't really see the problem.  If the user 
turns on the bit, it'll result in at most one more interrupt, right?  If he 
turns off the bit, then he doesn't want interrupts.

On Friday, November 05, 2010 10:30:15 am Alex Williamson wrote:
quoted text
> Tom,
> 
> Since we use INTX_DISABLE internally for PCI 2.3 devices, it's probably
> not a good idea to allow vfio users direct access to it.  In trying to
> virtualize it, I stumbled on some config space virtualization issues.
> I think we want vconfig and the value written to hardware to be different
> when there are virtualized bits, but we lump them together.  I think this
> is why I've never been able to rely on the memory enable bit of config
> space through vfio.  With this first patch, all virtualized bits that
> are writable are sticky in vconfig.  Non-writable bits come from either
> the old value or the physical hardware depending on whether it's
> virtualized.  This means we can get rid of a lot of duplicated setting
> and reading of vconfig, and only add code for more complicated
> behaviors.  This is tricky code, to please double check that I'm not
> doing something stupid.  Thanks,
> 
> Alex
> 
> ---
> 
> Alex Williamson (2):
>       vfio: Virtualize PCI_COMMAND_INTX_DISABLE
>       vfio: Fix config space virtualization
> 
> 
>  drivers/vfio/vfio_intrs.c      |   38 ++++++++----
>  drivers/vfio/vfio_main.c       |   14 ++++
>  drivers/vfio/vfio_pci_config.c |  131
> ++++++++++++---------------------------- include/linux/vfio.h           | 
>   4 +
>  4 files changed, 84 insertions(+), 103 deletions(-)
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/