qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] memory: Provide separate handling of unassi


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/2] memory: Provide separate handling of unassigned io ports accesses
Date: Mon, 5 Aug 2013 13:07:59 +0200

 On Aug 05 2013, Jan Kiszka wrote:
> On 2013-08-05 12:36, Peter Maydell wrote:
> > On 5 August 2013 11:30, Jan Kiszka <address@hidden> wrote:
> >> On 2013-08-05 11:59, Peter Maydell wrote:
> >>> Or do you mean that if we had:
> >>>
> >>>  [ system memory region, with its own default read/write ops ]
> >>
> >> I cannot imagine how this could work. The system memory region has no
> >> clue about what the regions below it can handle and what not. So it has
> >> to pass through the io window.
> > 
> > The system memory region's just a container, you can add a
> > background region to it at lowest-possible-priority, which
> > then takes accesses which are either (a) not in any subregion
> > or (b) in a subregion but that container doesn't specify
> > its own io ops and nothing in that container handles the
> > access. (Or you could create the system memory region with
> > its own IO ops, which would have the same effect.)
> 
> First, we do not render MMIO and IO within the same address space so
> far.

This is not true, we do render the I/O address space in system memory
on machines that support PCI or ISA but are not x86.  We do that through
an alias of get_system_io(), but that doesn't change the picture.

> But even if we would, the IO container now catches all accesses, so
> the system memory region will never have its default handler run for
> that window.

This however is true, and is the right thing to do.  It is also
very similar to the workaround that Richard did on Alpha (commit
3661049fec64ffd7ab008e57e396881c6a4b53a4) and it should be possible
to revert that one indeed.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]