Re: ioperm problem

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Nov 17, 2011 at 10:05:57AM -0800, Jeremy Fitzhardinge wrote:
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
> 
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it.  Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.

There are three different cases here:
 - Nvidia and VBE tool. They seem to do a lot of poking and Ben
   needed some way of making it work. Naturally the nouveau driver
   is not doing this.. This is in Dom0.

 - DVB cards. I *think* that the problem some folks have with passing
   in the DVB cards is that the 'scan' tools used to jump frequencies
   poke at those IO-ports. But I am not 100% sure about it, and need
   to look in more details at the drivers itself. The person reporting
   this was running the DVB card in Dom0.

 - Lastly the PCI passthrough of NVidia/ATI card in the guest. I think
   one person is trying to do it while running the guest in paravirtualized
   mode, in which case some help in doing those hypercall is needed.
   But if one were to do this in fully virtualized that means QEMU ends up
   trapping those I/O port accesses and it itself pokes them in the PCI card.
   But since QEMU is running in dom0 and dom0 is PV, that leads back to the
   VGA I/O ports not being allowed to poke as we don't have the ioperm hypercall.

This all sounds right, but in practice it might be something entirely
different..