[Qemu-devel] Endian control register

[Qemu-devel] Endian control register

[Benjamin Herrenschmidt]

Hi !

So while trying to solve an issue we have with qemu/kvm and powerpc who
can be both LE and BE nowadays, we thought the ideal solution would be
to have a register in the emulated VGA to control the endian.

Since qemu wishes to remain as much as possible in sync / compatible
with Bochs, I'm posting to this list so that the definition can be
made common even if Bochs doesn't have to actually implement it.

Now the basic idea is to have a bit indicating that endian control is
supported and a bit to control the guest endianness, set by the guest
appropriately (which affects all the pixel formats).

My original idea was to add a VBE register. However BOCHS seems to
be unhappy (after a quick glance at the source) if the guest tries to
read a non-existing register, so I suppose either the "support endian
switch" information needs to be encoded in an existing register in a way
that doesn't break existing code ... or the presence of the new register
advertised in such a way, for example via the PCI revision ID.

Note that I am not trying to support something like endian apertures and
that whole trainwreck that we had back in the day on BE machines. Simply
carry the guest endianness assuming that this affects all the pixel
formats which continue to be the classic ARGB ones, simply encoded with
the right endian (so 8bpp is unaffected for example).

Any suggestion ? Comment ? Flame ? :-)

Cheers,
Ben.

Re: [Qemu-devel] Endian control register

[Peter Maydell]

On 16 June 2014 11:30, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> So while trying to solve an issue we have with qemu/kvm and powerpc who
> can be both LE and BE nowadays, we thought the ideal solution would be
> to have a register in the emulated VGA to control the endian.

> Any suggestion ? Comment ? Flame ? :-)

My instinctive reaction is to ask if this exists in actual
VGA hardware. If not, then it doesn't really seem like it
belongs in our VGA device model...

thanks
-- PMM

Re: [Qemu-devel] Endian control register

[Benjamin Herrenschmidt]

On Mon, 2014-06-16 at 11:45 +0100, Peter Maydell wrote:
> On 16 June 2014 11:30, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > So while trying to solve an issue we have with qemu/kvm and powerpc who
> > can be both LE and BE nowadays, we thought the ideal solution would be
> > to have a register in the emulated VGA to control the endian.
> 
> > Any suggestion ? Comment ? Flame ? :-)
> 
> My instinctive reaction is to ask if this exists in actual
> VGA hardware. If not, then it doesn't really seem like it
> belongs in our VGA device model...

Actual VGA HW try to handle endianness using a range of more or less
broken solutions, so it's hard to compare :-)

A whole range of them historically such as older radeons had "apertures"
with a HW swap on the PCI to VRAM path allowing them internally to
continue using the same pixel format in VRAM. But that has issue, the
swappers must be adjusted for the actual bpp and things get tricky if
several objects in VRAM have different bpp which becomes common with
textures, or even render masks.

nVidia is a bit smarter and I think have the swapper on the units
consuming the pixels, I think they have per "object" endian settings but
I'm not 100% certain.

Recent radeons also have swappers per units which is a lot saner.

What I propose is somewhat equivalent to the two latter, but with only a
single object/unit, which is the framebuffer (since we don't do other
accelerations or drawing).

So yes, it somewhat relates to what is done elsewhere :-)

It is also the best solution we could find to the problem after some
discussion on IRC. The other solution is to try to hook when the guest
does the hypercall (yay paravirtualization !) to switch the endian mode
of interrupts and use it to "adjust" qemu internal vga byteswap but
that's frankly a lot more gross than having the VGA provide a
self-contained endian setting.

Cheers,
Ben.

Re: [Qemu-devel] Endian control register

[Benjamin Herrenschmidt]

On Mon, 2014-06-16 at 20:30 +1000, Benjamin Herrenschmidt wrote:
> Hi !
> 
> So while trying to solve an issue we have with qemu/kvm and powerpc who
> can be both LE and BE nowadays, we thought the ideal solution would be
> to have a register in the emulated VGA to control the endian.

No reply ... anybody out there ? :-) (Responding with a different
email address as I've had issues with gmail over eager spam filtering
lately).

So basically, I want to define VBE register 0xb as "endian control"
which may or may not be supported by a given platform. The problem
is how to expose to the OS that it exists (or doesn't) ?

Because if we just add it to qemu and make Linux start poking at
it (including on x86), then things will break when running Linux
under Bochs as it will hit a BX_PANIC when we access a VBE register
it doesn't know about.

My proposal is thus to add a backward compatible way to check for
that support before accessing it (and of course define the register
number in bochs so that this same number doesn't get reused later
for other purposes).

One simple option that will probably work is to add stuff to the
existing "GET_CAPABILITIES" mode. When that is selected, we could
for example make the "BANK" register return additional capability
flags, one of them being "endian support".

This gives us a way to add more extensions later on if needed as well.

Another option would be to use an unused bit if the ENABLE register
and simply force it to 1 on reads when the endian control register
is present... though in this case it might be a better idea to use
that bit to indicate the presence of "extended flags", use a new
register 0xb as "EXTENDED_FLAGS", and use a flag in there as indicative
of the presence of endian control which becomes register 0xc.

That way you also have room for more extensions if you wish to do
so in the future.

Any opinion ?

I'm happy to make & submit the patches, I just want an agreement
on the approach first.

Cheers,
Ben.

> Since qemu wishes to remain as much as possible in sync / compatible
> with Bochs, I'm posting to this list so that the definition can be
> made common even if Bochs doesn't have to actually implement it.
> 
> Now the basic idea is to have a bit indicating that endian control is
> supported and a bit to control the guest endianness, set by the guest
> appropriately (which affects all the pixel formats).
> 
> My original idea was to add a VBE register. However BOCHS seems to
> be unhappy (after a quick glance at the source) if the guest tries to
> read a non-existing register, so I suppose either the "support endian
> switch" information needs to be encoded in an existing register in a way
> that doesn't break existing code ... or the presence of the new register
> advertised in such a way, for example via the PCI revision ID.
> 
> Note that I am not trying to support something like endian apertures and
> that whole trainwreck that we had back in the day on BE machines. Simply
> carry the guest endianness assuming that this affects all the pixel
> formats which continue to be the classic ARGB ones, simply encoded with
> the right endian (so 8bpp is unaffected for example).
> 
> Any suggestion ? Comment ? Flame ? :-)
> 
> Cheers,
> Ben.
> 

Re: [Qemu-devel] Endian control register

[Benjamin Herrenschmidt]

On Mon, 2014-06-16 at 20:30 +1000, Benjamin Herrenschmidt wrote:
> Hi !
> 
> So while trying to solve an issue we have with qemu/kvm and powerpc who
> can be both LE and BE nowadays, we thought the ideal solution would be
> to have a register in the emulated VGA to control the endian.

No reply ... anybody out there ? :-)

So basically, I want to define VBE register 0xb as "endian control"
which may or may not be supported by a given platform. The problem
is how to expose to the OS that it exists (or doesn't) ?

Because if we just add it to qemu and make Linux start poking at
it (including on x86), then things will break when running Linux
under Bochs as it will hit a BX_PANIC when we access a VBE register
it doesn't know about.

My proposal is thus to add a backward compatible way to check for
that support before accessing it (and of course define the register
number in bochs so that this same number doesn't get reused later
for other purposes).

One simple option that will probably work is to add stuff to the
existing "GET_CAPABILITIES" mode. When that is selected, we could
for example make the "BANK" register return additional capability
flags, one of them being "endian support".

This gives us a way to add more extensions later on if needed as well.

Another option would be to use an unused bit if the ENABLE register
and simply force it to 1 on reads when the endian control register
is present... though in this case it might be a better idea to use
that bit to indicate the presence of "extended flags", use a new
register 0xb as "EXTENDED_FLAGS", and use a flag in there as indicative
of the presence of endian control which becomes register 0xc.

That way you also have room for more extensions if you wish to do
so in the future.

Any opinion ?

I'm happy to make & submit the patches, I just want an agreement
on the approach first.

Cheers,
Ben.

> Since qemu wishes to remain as much as possible in sync / compatible
> with Bochs, I'm posting to this list so that the definition can be
> made common even if Bochs doesn't have to actually implement it.
> 
> Now the basic idea is to have a bit indicating that endian control is
> supported and a bit to control the guest endianness, set by the guest
> appropriately (which affects all the pixel formats).
> 
> My original idea was to add a VBE register. However BOCHS seems to
> be unhappy (after a quick glance at the source) if the guest tries to
> read a non-existing register, so I suppose either the "support endian
> switch" information needs to be encoded in an existing register in a way
> that doesn't break existing code ... or the presence of the new register
> advertised in such a way, for example via the PCI revision ID.
> 
> Note that I am not trying to support something like endian apertures and
> that whole trainwreck that we had back in the day on BE machines. Simply
> carry the guest endianness assuming that this affects all the pixel
> formats which continue to be the classic ARGB ones, simply encoded with
> the right endian (so 8bpp is unaffected for example).
> 
> Any suggestion ? Comment ? Flame ? :-)
> 
> Cheers,
> Ben.
> 

Re: [Qemu-devel] Endian control register

[Benjamin Herrenschmidt]

On Mon, 2014-06-23 at 10:45 +1000, Benjamin Herrenschmidt wrote:
> 
> Another option would be to use an unused bit if the ENABLE register
> and simply force it to 1 on reads when the endian control register
> is present... though in this case it might be a better idea to use
> that bit to indicate the presence of "extended flags", use a new
> register 0xb as "EXTENDED_FLAGS", and use a flag in there as indicative
> of the presence of endian control which becomes register 0xc.
> 
> That way you also have room for more extensions if you wish to do
> so in the future.

I just remembered... we use 16-bit wide ports, we could just use the
top 8 bits of the enable register as "capabilities" ... 

Cheers,
Ben.