[RFC/PATCH 0/16] Ops based MSI Implementation
David Miller
davem at davemloft.net
Mon Jan 29 10:31:56 EST 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sun, 28 Jan 2007 15:36:20 -0700
> That might be the right solution. I don't know. But that is one
> among several that your HV interface is wrong and probably should be
> fixed at the HV. I definitely have no intentions of encouraging
> another HV to emulate the brittleness of your solution.
>
> Nor do I want to ask device drivers to preallocate 4096 interrupts
> just in case they need them. Even if batch allocation makes sense
> always asking for the maximum possible that you might use is overkill.
Other platforms do this and I think it is totally reasonable
to protect the defined PCI config register writes for MSI
and MSI-X behind the hypervisor calls.
It is one of several legitimate ways to keep a PCI device from
transmitting random junk to other devices which are on behind the same
PCI controller yet belong to another virtual domain.
Another solution is to have a PCI-E bridges define the unit of
splitability between virtual domains, and have those PCI-E bridges
protect each other from inter-domain MSI message writes.
Both solutions are valid, and each platform and hypervisor may make
either decision and it is reasonable.
About your argument of a MSI-Y, these platforms simply don't support
such devices and the people who design these systems and hypervisors
absolutely accept that limitation as a design trade off. It's not a
bad thing.
Look, I have no idea where all this resistence come from to abstract
this stuff behind enough levels to support things like RTAS et al.
properly. Please stop it now.
More information about the Linuxppc-dev
mailing list