Re: [Qemu-devel] [RFC] Memory API

[Jamie Lokier]

Gleb Natapov wrote:
> On Sun, May 22, 2011 at 10:50:22AM +0300, Avi Kivity wrote:
> > On 05/20/2011 02:25 PM, Gleb Natapov wrote:
> > >>
> > >>  A) Removing regions will change significantly. So far this is done by
> > >>  setting a region to IO_MEM_UNASSIGNED, keeping truncation. With the new
> > >>  API that will be a true removal which will additionally restore hidden
> > >>  regions.
> > >>
> > >And what problem do you expect may arise from that? Currently accessing
> > >such region after unassign will result in undefined behaviour, so this
> > >code is non working today, you can't make it worse.
> > >
> > 
> > If the conversion were perfect then yes.  However there is a
> > possibility that the conversion will not be perfect.
> > 
> > It's also good to have to have the code document its intentions.  If
> > you see _overlap() you know there is dynamic address decoding going
> > on, or something clever.
> > 
> > >>  B) Uncontrolled overlapping is a bug that should be caught by the core,
> > >>  and a new API is a perfect chance to do this.
> > >>
> > >Well, this will indeed introduce the difference in behaviour :) The guest
> > >that ran before will abort now. Are you actually aware of any such
> > >overlaps in the current code base?
> > 
> > Put a BAR over another BAR, then unmap it.
> > 
> _overlap will not help with that. PCI BARs can overlap, so _overlap will
> be used to register them. You do not what to abort qemu when guest
> configure overlapping PCI BARs don't you?

I'd rather guests have no way to abort qemu, except by explicit
agreement... even if they program BARs randomly or do anything else.
Right now my virtual server provider won't let me run my own kernels
because they are paranoid that a non-approved kernel might crash KVM.
Which is reasonable.  Even so, it's possible to reprogram BARs from
guest userspace.

Hot-adding devices, including ones with MMIO or IO addresses that
overlap another existing device, shouldn't make qemu abort either.
Perhaps disable the device, perhaps respond with an error, that's all.

Even then, if hot-adding some ISA device overlaps an existing PCI BAR,
it would be preferable if the devices (probably both of them) simply
didn't receive any bus cycles until the BARs were moved elsewhere,
maybe triggered PCI bus errors or MCEs or something like that, rather
than introducing never-tested-in-practice management-visible state
such as a "disabled" or "refused" device.

I don't know if qemu has devices like this, but many real ISA devices
have software-configurable IO, MMI and IRQ settings (ISAPNP) - it's
not just PCI.

I thoroughly approve of the plan to keep track of overlapping regions
so that adding/removing them has no side effect.  When they conflict
at equal priorities I suggest a good behaviour would be:

   - No access to the underlying device
   - MCE interrupt or equivalent, signalling a bus error

Then the order of registration doesn't make any difference, which is good.

-- Jamie