Re: [Qemu-devel] [PATCH 3/3] vhost: roll our own cpu map variant

[Michael S. Tsirkin]

On Wed, Mar 30, 2011 at 05:26:22PM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 30, 2011 at 5:09 PM, Michael S. Tsirkin <address@hidden> wrote:
> > On Tue, Mar 29, 2011 at 11:53:54AM +0100, Stefan Hajnoczi wrote:
> >> On Mon, Mar 28, 2011 at 10:14 PM, Michael S. Tsirkin <address@hidden> 
> >> wrote:
> >> > vhost used cpu_physical_memory_map to get the
> >> > virtual address for the ring, however,
> >> > this will exit on an illegal RAM address.
> >> > Since the addresses are guest-controlled, we
> >> > shouldn't do that.
> >> >
> >> > Switch to our own variant that uses the vhost
> >> > tables and returns an error instead of exiting.
> >>
> >> We should make all of QEMU more robust instead of just vhost.  Perhaps
> >> introduce cpu_physical_memory_map_nofail(...) that aborts like the
> >> current cpu_physical_memory_map() implementation and then make non-hw/
> >> users call that one.  hw/ users should check for failure.
> >>
> >> Stefan
> >
> > Yea, well ... at least vhost-net wants to also check
> > it is given a ram address, not some other physical address.
> > We could generally replace the memory management in vhost-net
> > by some other logic, when that's done this one can
> > go away as well.
> 
> Sounds like you do not want to refactor physical memory access for
> non-vhost.  Fair enough but we have to do it sooner or later in order
> to make all of QEMU more robust.  If vhost-net is protected but the
> IDE CD-ROM and virtio-blk disk still have issues then we haven't
> reached our goal yet.  Any way I can convince you to do a generic API?
> :)
> 
> Stefan

If you are talking about splitting real ram from non ram
and creating a generic API for that, you don't need to convince me,
but I can't commit to implementing it right now.

-- 
MST