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 <m...@redhat.com> 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 <m...@redhat.com> > >> 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
