qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH, RFC 0/4] Byte swapping I/O memory, preview
Date: Thu, 27 May 2010 17:43:45 +0300	[thread overview]
Message-ID: <20100527144345.GB8314@redhat.com> (raw)
In-Reply-To: <AANLkTimN8g_nqmX7b3XgykX69ejh83C5nc-4q9B3zUNC@mail.gmail.com>

On Sun, May 23, 2010 at 08:34:17PM +0000, Blue Swirl wrote:
> Hi,
> 
> The overall plan is to add a new flag, IO_MEM_BSWAP, which triggers
> byte swapping inside CPU load/store functions. Convert all PCI devices
> to register their memory areas via the PCI host. Then the big endian
> PCI hosts enable IO_MEM_BSWAP for all registered regions,
> simultaneously all PCI devices stop swapping bytes. Some more PCI
> devices can probably be compiled once, though since this is not
> Generic DMA, there won't be too many.
> 
> The patches are not acceptable yet, APB part should be moved from 1/4
> to 2/4 even though it means a bit of extra work, this breaks
> bisection. Instead of PCIBus, the registration functions should take a
> PCIDevice parameter.

So if we rewrite all devices anyway, let's finally move memory
mapping for BARs out of devices and into pci.c.
As it is, memory is mapped by devices but unmapped by pci.c

> 3/4 breaks several architectures. 4/4 should
> remove byte swapping from devices. VGA is a problem because the byte
> swaps are in common functions.

Yes, VGA is hairy.

> Sparc64 almost works, other architectures show blank screen.
> 
> Anyway, I thought I'll send the patches for comments. Especially, is
> the idea of using IO_MEM_BSWAP viable?
> 
> Blue Swirl (4):
>   pci: add I/O registration functions
>   Convert PCI devices to use pci_register_memory()
>   Implement byte swapped MMIO type
>   apb: use IO_MEM_BSWAP with device registration
> 
>  cpu-common.h       |    3 +-
>  hw/apb_pci.c       |   23 ++++++++++++++++-
>  hw/cirrus_vga.c    |   12 ++++----
>  hw/e1000.c         |    2 +-
>  hw/eepro100.c      |    2 +-
>  hw/isa.h           |    1 +
>  hw/isa_mmio.c      |   18 ++++++++++++-
>  hw/lsi53c895a.c    |    4 +-
>  hw/macio.c         |   24 +++++++++---------
>  hw/msix.c          |    4 +-
>  hw/openpic.c       |    6 ++--
>  hw/pci.c           |   64 ++++++++++++++++++++++++++++-------------------
>  hw/pci.h           |    9 ++++++-
>  hw/pcnet.c         |    3 +-
>  hw/rtl8139.c       |    2 +-
>  hw/sun4u.c         |    7 ++++-
>  hw/usb-ohci.c      |    2 +-
>  hw/vga-pci.c       |    4 +-
>  hw/vmware_vga.c    |    7 ++---
>  hw/wdt_i6300esb.c  |    2 +-
>  softmmu_template.h |   69 ++++++++++++++++++++++++++++++++++++++++++++++------
>  21 files changed, 190 insertions(+), 78 deletions(-)

      reply	other threads:[~2010-05-27 14:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-23 20:34 [Qemu-devel] [PATCH, RFC 0/4] Byte swapping I/O memory, preview Blue Swirl
2010-05-27 14:43 ` Michael S. Tsirkin [this message]

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=20100527144345.GB8314@redhat.com \
    --to=mst@redhat.com \
    --cc=blauwirbel@gmail.com \
    --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).