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 <b...@kernel.crashing.org> 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
