qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 3/3] vhost: roll our own cpu map variant
Date: Wed, 30 Mar 2011 18:59:00 +0100

On Wed, Mar 30, 2011 at 5:59 PM, Michael S. Tsirkin <address@hidden> 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 <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.

Okay, userspace virtio will be able to use it as well in the future.

Stefan



reply via email to

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