All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>,
	kvm-ppc@vger.kernel.org, Scott Wood <scottwood@freescale.com>,
	Alex Williamson <Alex.Williamson@redhat.com>
Subject: Re: Question about removing memslots
Date: Wed, 28 Mar 2012 10:05:40 +0000	[thread overview]
Message-ID: <4F72E274.2090007@redhat.com> (raw)
In-Reply-To: <1332928770.2882.98.camel@pasglop>

On 03/28/2012 11:59 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
>
> > > Now I see that x86 just seems to flush everything, which is quite heavy
> > > handed considering how often cirrus does it, but maybe it doesn't have a
> > > choice (lack of reverse mapping from GPA ?).
> > 
> > We do have a reverse mapping, so we could easily flush just a single
> > slot.  The reason it hasn't been done is that slot changes are very are
> > on x86.  They're usually only done by 16-bit software; 32-bit software
> > just maps the entire framebuffer BAR and accesses it directly.  It's
> > also usually done in a tight loop, so flushing everything doesn't have a
> > large impact (and with a 20-bit address space, you couldn't cause a
> > large impact if you wanted to - memory is all of 256 pages).
>
> Right ... except that it definitely seems to be happening here with
> cirrusfb in the guest kernel :-)
>
> Every time it does an imageblit it switches the BAR to emulation and
> back to direct mapping when the "upload" of the image is complete.

That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:

0000000000000000-7ffffffffffffffe (prio 0, RW): pci
  00000000000a0000-00000000000bffff (prio 1, RW): cirrus-lowmem-container
    00000000000a0000-00000000000a7fff (prio 1, RW): alias vga.bank0
@vga.vram 0000000000000000-0000000000007fff
    00000000000a0000-00000000000bffff (prio 0, RW): cirrus-low-memory
    00000000000a8000-00000000000affff (prio 1, RW): alias vga.bank1
@vga.vram

^ those are continuously flipped when running 16-bit software

0000000000008000-000000000000ffff
  00000000000c0000-00000000000dffff (prio 1, RW): pc.rom
  00000000000e0000-00000000000fffff (prio 1, R-): isa-bios
  00000000fc000000-00000000fdffffff (prio 1, RW): cirrus-pci-bar0
    00000000fc000000-00000000fc7fffff (prio 1, RW): vga.vram
    00000000fc000000-00000000fc7fffff (prio 0, RW): cirrus-linear-io
    00000000fd000000-00000000fd3fffff (prio 0, RW): cirrus-bitblt-mmio

^ the cirrus BAR, write to 0xfc000000 and you hit vga.vram, write to
0xfd000000 and you trigger a bitblt.

  00000000feba0000-00000000febbffff (prio 1, RW): e1000-mmio
  00000000febf0000-00000000febf0fff (prio 1, RW): cirrus-mmio

A guest driver problem perhaps?


> The X cirrus driver doesn't seem to trigger that (at least didn't from
> my limited testing so far) so it may not be using host data blits ...
> I'll have to compare what they do in more details.

Or maybe it understands the BAR layout better.

-- 
error compiling committee.c: too many arguments to function


WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>,
	kvm-ppc@vger.kernel.org, Scott Wood <scottwood@freescale.com>,
	Alex Williamson <Alex.Williamson@redhat.com>
Subject: Re: Question about removing memslots
Date: Wed, 28 Mar 2012 12:05:40 +0200	[thread overview]
Message-ID: <4F72E274.2090007@redhat.com> (raw)
In-Reply-To: <1332928770.2882.98.camel@pasglop>

On 03/28/2012 11:59 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
>
> > > Now I see that x86 just seems to flush everything, which is quite heavy
> > > handed considering how often cirrus does it, but maybe it doesn't have a
> > > choice (lack of reverse mapping from GPA ?).
> > 
> > We do have a reverse mapping, so we could easily flush just a single
> > slot.  The reason it hasn't been done is that slot changes are very are
> > on x86.  They're usually only done by 16-bit software; 32-bit software
> > just maps the entire framebuffer BAR and accesses it directly.  It's
> > also usually done in a tight loop, so flushing everything doesn't have a
> > large impact (and with a 20-bit address space, you couldn't cause a
> > large impact if you wanted to - memory is all of 256 pages).
>
> Right ... except that it definitely seems to be happening here with
> cirrusfb in the guest kernel :-)
>
> Every time it does an imageblit it switches the BAR to emulation and
> back to direct mapping when the "upload" of the image is complete.

That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:

0000000000000000-7ffffffffffffffe (prio 0, RW): pci
  00000000000a0000-00000000000bffff (prio 1, RW): cirrus-lowmem-container
    00000000000a0000-00000000000a7fff (prio 1, RW): alias vga.bank0
@vga.vram 0000000000000000-0000000000007fff
    00000000000a0000-00000000000bffff (prio 0, RW): cirrus-low-memory
    00000000000a8000-00000000000affff (prio 1, RW): alias vga.bank1
@vga.vram

^ those are continuously flipped when running 16-bit software

0000000000008000-000000000000ffff
  00000000000c0000-00000000000dffff (prio 1, RW): pc.rom
  00000000000e0000-00000000000fffff (prio 1, R-): isa-bios
  00000000fc000000-00000000fdffffff (prio 1, RW): cirrus-pci-bar0
    00000000fc000000-00000000fc7fffff (prio 1, RW): vga.vram
    00000000fc000000-00000000fc7fffff (prio 0, RW): cirrus-linear-io
    00000000fd000000-00000000fd3fffff (prio 0, RW): cirrus-bitblt-mmio

^ the cirrus BAR, write to 0xfc000000 and you hit vga.vram, write to
0xfd000000 and you trigger a bitblt.

  00000000feba0000-00000000febbffff (prio 1, RW): e1000-mmio
  00000000febf0000-00000000febf0fff (prio 1, RW): cirrus-mmio

A guest driver problem perhaps?


> The X cirrus driver doesn't seem to trigger that (at least didn't from
> my limited testing so far) so it may not be using host data blits ...
> I'll have to compare what they do in more details.

Or maybe it understands the BAR layout better.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-03-28 10:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28  7:24 Question about removing memslots Benjamin Herrenschmidt
2012-03-28  7:24 ` Benjamin Herrenschmidt
2012-03-28  9:37 ` Avi Kivity
2012-03-28  9:37   ` Avi Kivity
2012-03-28  9:59   ` Benjamin Herrenschmidt
2012-03-28  9:59     ` Benjamin Herrenschmidt
2012-03-28 10:05     ` Avi Kivity [this message]
2012-03-28 10:05       ` Avi Kivity
2012-03-28 10:17       ` Benjamin Herrenschmidt
2012-03-28 10:17         ` Benjamin Herrenschmidt
2012-03-28 10:51         ` Avi Kivity
2012-03-28 10:51           ` Avi Kivity
2012-03-28 21:04           ` Benjamin Herrenschmidt
2012-03-28 21:04             ` Benjamin Herrenschmidt
2012-03-29  9:36             ` Avi Kivity
2012-03-29  9:36               ` Avi Kivity
2012-03-29 11:46               ` Benjamin Herrenschmidt
2012-03-29 11:46                 ` Benjamin Herrenschmidt
2012-03-29 13:49               ` Gerd Hoffmann
2012-03-29 13:49                 ` Gerd Hoffmann
2012-03-29  5:15   ` Takuya Yoshikawa
2012-03-29  5:15     ` Takuya Yoshikawa
2012-03-29  9:44     ` Avi Kivity
2012-03-29  9:44       ` Avi Kivity
2012-03-29 15:21       ` Takuya Yoshikawa
2012-03-29 15:21         ` Takuya Yoshikawa
2012-03-29 15:26         ` Avi Kivity
2012-03-29 15:26           ` Avi Kivity
2012-03-29 15:35           ` Takuya Yoshikawa
2012-03-29 15:35             ` Takuya Yoshikawa

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=4F72E274.2090007@redhat.com \
    --to=avi@redhat.com \
    --cc=Alex.Williamson@redhat.com \
    --cc=agraf@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=scottwood@freescale.com \
    /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.