From: Avi Kivity <avi@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API
Date: Sun, 22 May 2011 09:40:57 +0300 [thread overview]
Message-ID: <4DD8AFF9.5080205@redhat.com> (raw)
In-Reply-To: <BANLkTin0OHOA4y-Tagt670Um4af2tpbLDw@mail.gmail.com>
On 05/20/2011 09:16 PM, Blue Swirl wrote:
> On Fri, May 20, 2011 at 5:46 PM, Anthony Liguori<anthony@codemonkey.ws> wrote:
> > On 05/20/2011 09:40 AM, Richard Henderson wrote:
> >>
> >> On 05/20/2011 07:31 AM, Anthony Liguori wrote:
> >>>
> >>> But is this a characteristic of devices or is this a characteristic of
> >>> the chipset/CPU?
> >>
> >> Chipset.
> >
> > So if the chipset only allows accesses that are 64-bit, then you'll want to
> > have hierarchical dispatch filter non 64-bit accesses and raise an MCE
> > appropriately.
> >
> > So you don't need anything in MemoryRegion, you need code in the dispatch
> > path.
>
> Sparc (32/64) systems are also very picky about wrong sized accesses.
> I think the buses have lines for access size and the device can (and
> they will) signal an error in these cases. Then the bus controller
> will raise an NMI.
>
> I think the easiest way to handle this could be to use overlapping
> registrations for specific sizes. Then we could make a default error
> generator device, which would just signal NMI/MCE on any access. It
> would register for all of the picky area with lowest possible
> priority. Other devices would register the small working access areas
> with no knowledge about this error generator device. Any correct
> access should go to other devices, bad accesses to the error
> generator.
>
> Though this would not be very different from current unassigned access handling.
The MemoryRegion way of doing it would be to register the MemoryRegion
of the bus with the picky attributes. Any sub-regions will inherit the
property.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2011-05-22 6:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 14:12 [Qemu-devel] [RFC v1] Memory API Avi Kivity
2011-05-19 14:12 ` [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API Avi Kivity
2011-05-19 19:07 ` Alex Williamson
2011-05-20 9:18 ` Avi Kivity
2011-05-19 19:27 ` Jan Kiszka
2011-05-20 9:20 ` Avi Kivity
2011-05-19 20:43 ` Anthony Liguori
2011-05-20 9:23 ` Avi Kivity
2011-05-20 14:06 ` Richard Henderson
2011-05-20 14:31 ` Anthony Liguori
2011-05-20 14:40 ` Richard Henderson
2011-05-20 14:46 ` Anthony Liguori
2011-05-20 18:16 ` Blue Swirl
2011-05-22 6:40 ` Avi Kivity [this message]
2011-05-22 6:39 ` Avi Kivity
2011-05-22 15:46 ` Anthony Liguori
2011-05-22 15:52 ` Avi Kivity
2011-05-22 6:38 ` Avi Kivity
2011-05-22 15:44 ` Anthony Liguori
2011-05-22 15:56 ` Avi Kivity
2011-05-22 7:01 ` Avi Kivity
2011-05-19 21:04 ` Stefan Weil
2011-05-20 9:26 ` Avi Kivity
2011-05-19 21:11 ` Stefan Hajnoczi
2011-05-20 9:28 ` Avi Kivity
2011-05-20 17:59 ` Blue Swirl
2011-05-22 6:45 ` Avi Kivity
2011-05-22 9:32 ` Blue Swirl
2011-05-22 11:36 ` Avi Kivity
2011-05-22 12:06 ` Blue Swirl
2011-05-22 12:18 ` Avi Kivity
2011-05-22 15:32 ` Blue Swirl
2011-05-22 15:36 ` Avi Kivity
2011-05-22 7:04 ` Avi Kivity
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=4DD8AFF9.5080205@redhat.com \
--to=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).