From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Avi Kivity <avi@redhat.com>
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: Thu, 29 Mar 2012 08:04:18 +1100 [thread overview]
Message-ID: <1332968658.2882.108.camel@pasglop> (raw)
In-Reply-To: <4F72ED38.5000007@redhat.com>
On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote:
> Ah, then it's not a guest problem, it's how the chip was designed.
> Newer chips do allow a workaround (GR31 bit 6):
>
> 6 System Source Location (Revision A): If this bit is ‘1’, the CL-GD546X
> responds to write accesses at 000BC000h–000BFFFFh for color-expand
> BitBLTs. This frees the linear address apertures for other, concurrent
> accesses. If this bit is ‘0’, the CL-GD546X uses the linear aperture for
> BitBLTs (compatible with CL-GD543X/’4X).
> System Source Location (Revision B): If this bit is ‘1’,
> system-to-screen BitBLTs use the second 16-Mbyte window specified in
> PCI10. This allows direct frame buffer accesses in the first window to
> be mixed with system-to-screen writes in the second window without
> restrictions.
>
> If a system-to-screen BitBLT requiring data is not active, writes to the
> second window complete in the minimum time and the data is discarded.
> Writes to the first window are ignored by the BitBLT engine (but are
> taken as direct writes to the frame buffer).
>
> If this bit is ‘0’, system-to-screen BitBLTs use the first 16-Mbyte
> window (compatible with CL-GD543X/’4X).
>
> But it looks like this refers to 546x, even though I found it in the
> 5446 manual.
Right. The first option uses legacy VGA memory which I don't always have
access to so that's not really an option for cirrusfb in general (in
fact I made it not use IO either, it's doing full MMIO for configuring
the CRTCs as well).
I could (I have patches to do so) open a ISA/VGA memory window on the
bridge, in fact I need that for the X driver to work for other reasons,
but I'd rather not have cirrusfb deal with that.
The funny thing here is we have "clean" APIs to let userspace map (when
available) and access legacy VGA memory & IO ports, but we don't have a
good in-kernel API to do the same thing :-) On x86 things are somewhat
easy because it's just all hard coded and there's really only one PCI do
main but on anything else it's a mess.
In any case, X seems to avoid it, maybe nobody does color expansion
nowadays (I suppose modern desktops don't, maybe using ancient X apps
might trigger that path). So no biggie. I'll have to fix KVM powerpc
dealing with memslot changes anyways.
Thanks for your help,
Cheers,
Ben.
next prev parent reply other threads:[~2012-03-28 21:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 7:24 Question about removing memslots Benjamin Herrenschmidt
2012-03-28 9:37 ` Avi Kivity
2012-03-28 9:59 ` Benjamin Herrenschmidt
2012-03-28 10:05 ` Avi Kivity
2012-03-28 10:17 ` Benjamin Herrenschmidt
2012-03-28 10:51 ` Avi Kivity
2012-03-28 21:04 ` Benjamin Herrenschmidt [this message]
2012-03-29 9:36 ` Avi Kivity
2012-03-29 11:46 ` Benjamin Herrenschmidt
2012-03-29 13:49 ` Gerd Hoffmann
2012-03-29 5:15 ` Takuya Yoshikawa
2012-03-29 9:44 ` Avi Kivity
2012-03-29 15:21 ` Takuya Yoshikawa
2012-03-29 15:26 ` Avi Kivity
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=1332968658.2882.108.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Alex.Williamson@redhat.com \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox