On Tue, 2012-01-31 at 22:19 +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 31, 2012 at 08:16:31PM +0100, Jan Kiszka wrote:
> > On 2012-01-31 20:12, Michael S. Tsirkin wrote:
> > > On Tue, Jan 31, 2012 at 12:07:39PM -0700, Alex Williamson wrote:
> > >> On Tue, 2012-01-31 at 19:40 +0200, Michael S. Tsirkin wrote:
> > >>> On Sat, Jan 28, 2012 at 07:22:09AM -0700, Alex Williamson wrote:
> > >>>> Per the PCI spec, all vectors should be masked at handoff.
> > >>>>
> > >>>> Signed-off-by: Alex Williamson <alex.williamson@xxxxxxxxxx>
> > >>>> ---
> > >>>>
> > >>>> hw/device-assignment.c | 20 +++++++++++++++++++-
> > >>>> 1 files changed, 19 insertions(+), 1 deletions(-)
> > >>>>
> > >>>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > >>>> index af614d3..6efa219 100644
> > >>>> --- a/hw/device-assignment.c
> > >>>> +++ b/hw/device-assignment.c
> > >>>> @@ -1462,6 +1462,22 @@ static const MemoryRegionOps msix_mmio_ops = {
> > >>>> },
> > >>>> };
> > >>>>
> > >>>> +static void msix_reset(AssignedDevice *dev)
> > >>>> +{
> > >>>> + MSIXTableEntry *entry;
> > >>>> + int i;
> > >>>> +
> > >>>> + if (!dev->msix_table) {
> > >>>> + return;
> > >>>> + }
> > >>>> +
> > >>>> + memset(dev->msix_table, 0, 0x1000);
> > >>>> +
> > >>>> + for (i = 0, entry = dev->msix_table; i < dev->msix_max; i++, entry++) {
> > >>>> + entry->ctrl = 0x1; /* Masked */
> > >>>
> > >>> This is broken for BE hosts.
> > >>
> > >> Show me a BE host that even remotely works with this device assignment
> > >> implementation. Thanks,
> > >>
> > >> Alex
> > >
> > > I don't get it. Yes lots of cleanup is needed but why add more broken
> > > code?
> >
> > At some point, we will just do this via the PCI core, and that will have
> > to do it correctly anyway. This code here is supposed to be removed again.
> >
> > Jan
>
> Either we say this is all dead code, then
> let's just fix bugs until it is rewritten.
> To fix the bug, all we need is patch 9, maybe 6 and 7.
>
> Or there is intent to maintain it going forward
> then, methinks, it needs to be brought up to
> some minimal standards.
There's minimal standards and then there's endian neutrality and non-x86
support for a piece of code that, I think, is probably never going to
see qemu.git. There's a big gap between those. I'd love for us to move
to vfio, but for now we're stuck with this and I'll try to update it and
make it a little better each time. Looking out for big endian hosts
isn't high on my priority list for this code though. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
