On Wed, Mar 30, 2011 at 5:59 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > 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.
Okay, userspace virtio will be able to use it as well in the future. Stefan