From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: bochs-developers@lists.sourceforge.net
Cc: paulus@samba.org, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>
Subject: [Qemu-devel] Endian control register
Date: Mon, 16 Jun 2014 20:30:04 +1000 [thread overview]
Message-ID: <1402914604.7661.46.camel@pasglop> (raw)
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.
next reply other threads:[~2014-06-16 10:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 10:30 Benjamin Herrenschmidt [this message]
2014-06-16 10:45 ` [Qemu-devel] Endian control register Peter Maydell
2014-06-16 11:07 ` Benjamin Herrenschmidt
2014-06-23 0:43 ` Benjamin Herrenschmidt
2014-06-23 0:45 ` Benjamin Herrenschmidt
2014-06-23 3:32 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402914604.7661.46.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=bochs-developers@lists.sourceforge.net \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).