Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes

[Alexander Graf]

On 18.06.14 00:55, Benjamin Herrenschmidt wrote:
> On Tue, 2014-06-17 at 23:12 +0100, Peter Maydell wrote:
> > On 17 June 2014 22:32, Benjamin Herrenschmidt <address@hidden> wrote:
> > > Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
> > > cleaner) to what I did in my patch which is when the pseries guest calls
> > > the hypervisor call to change the interrupt endian mode, we notify VGA
> > > and switch its endian mode, so we work "by default" with kernels not
> > > updated to know about that register. But this is open for debate. It's
> > > somewhat "acceptable" in the context of our hypercall being a
> > > "paravirtualized" interface, so it can be argued that the hypercall
> > > poking at the VGA chip is equivalent to some FW doing so :-)
> > I'm definitely against this. Have your guest change the behaviour
> > of the VGA device by explicitly prodding the VGA device, not by
> > back-door side-effects of something else that it happens to do
> > on one particular guest for one particular architecture, please.
> But that means modifying guests ... obviously you live in a world where
> you don't have to live with existing enterprise distros backward
> compatibility :-)
>
> I understand the reluctance against backdoor side effects in general,
> but as I said, this is a hypervisor call that basically says "change
> system endianness". It does make some amount of sense to have in that
> case the hypervisor (which here is qemu) go adjust the endianness
> setting in some devices as well as the cores.

Semantically the H_SET_MODE(LE) hypercall is on the same level as PSCI. 
Some code somewhere (Trustzone in the guest on ARM or QEMU) runs some 
code to "do magic".

So for the sake of the discussion imagine this code would live inside of 
guest context. It can't for us, as hypercalls always trap into KVM or 
QEMU, but semantically the code shouldn't be able to do too much more 
than anything coming from the guest should be able to do.

Imagine the code that runs here loops through all PCI devices, looks for 
BOCHS VGA adapters and pokes that endian register.

This is essentially the interface that Ben is suggesting here.

Given that, the prerequisite to that interface is to have a guest 
exposed register to flip the endianness in the first place. I think it 
makes most sense to settle on that register first, then talk about 
potential backwards compat hacks that we could do on hypercalls with 
that register.

Of course, the side effect that H_SET_MODE(LE) flips the VGA endianness 
needs to be documented in sPAPR as well if we want to go down that path. 
sPAPR is the hypercall specification we implement with -M pseries.


Alex