All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org, "Anthony Liguori" <aliguori@us.ibm.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Alexander Graf" <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH] virtio-pci: replace byte swap hack
Date: Thu, 10 Jan 2013 00:06:08 +0200	[thread overview]
Message-ID: <20130109220608.GA12062@redhat.com> (raw)
In-Reply-To: <CAAu8pHt40D9bW-7WsUPDELXGHB_oc7yUTsuxnXoLkfaz=UaDLw@mail.gmail.com>

On Wed, Jan 09, 2013 at 08:39:08PM +0000, Blue Swirl wrote:
> On Mon, Jan 7, 2013 at 4:11 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Sun, Jan 06, 2013 at 08:04:39PM +0000, Blue Swirl wrote:
> >> On Sun, Jan 6, 2013 at 6:25 PM, Andreas Färber <afaerber@suse.de> wrote:
> >> > Am 06.01.2013 14:17, schrieb Alexander Graf:
> >> >>
> >> >> On 30.12.2012, at 13:55, Blue Swirl wrote:
> >> >>
> >> >>> Remove byte swaps by declaring the config space
> >> >>> as native endian.
> >> >>
> >> >> This is wrong. Virtio-pci config space is split into 2 regions. One with native endianness, the other one with little endian.
> >> >
> >> > Can that MemoryRegion be split in two?
> >>
> >> Yes, but unfortunately the offset for the second region depends on if
> >> MSIX is enabled or not. PCI layer manages these bits without the
> >> device seeing any changes.
> >>
> >> This could be handled by introducing a callback at PCI layer to inform
> >> interested devices about changes to MSIX setup, or even generalized:
> >> inform devices about changes within any set of bits specified by the
> >> device.
> >
> > We already have a generic config_write callback and even use it in
> > virtio pci: virtio_write_config.  So you could simply do there:
> >
> >         if (region size != VIRTIO_PCI_CONFIG(dev)) {
> >                 resize regions
> >         }
> >
> > We would also have to resize to the default setup on
> > vm load and on vm reset.
> >
> > Overall not sure whether this would make the code cleaner or uglier.
> 
> I think it would be a net cleanup. Most of the ugliness comes from the
> poor device architecture.
> 
> There could be (unmeasurably) small performance gains since accesses
> to the two regions would be dispatched directly to the handlers. But
> if the MSIX mode bit is toggled very often compared to the accesses to
> config registers, it could actually cause some slow down due to
> adjustment to the offset with the memory API. How often does that
> happen, once per boot or more often? Are these registers accessed very
> often by the guests?

datapath accesses the memory a lot, while OTOH mode change happens once
per boot normally, so yes, in theory it's a minor optimization.  Likely
not measureable by itself but if others think it's cleaner to
structure code that way I sure won't object to a patch like that.

> >
> >> >
> >> > Andreas
> >> >
> >> > --
> >> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2013-01-09 22:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-30 12:55 [Qemu-devel] [PATCH] virtio-pci: replace byte swap hack Blue Swirl
2013-01-06 13:17 ` Alexander Graf
2013-01-06 18:25   ` Andreas Färber
2013-01-06 20:04     ` Blue Swirl
2013-01-07 16:11       ` Michael S. Tsirkin
2013-01-09 20:39         ` Blue Swirl
2013-01-09 22:06           ` Michael S. Tsirkin [this message]
2013-01-06 18:26   ` Blue Swirl
2013-01-06 18:50     ` Alexander Graf

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=20130109220608.GA12062@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.