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 17:26:22 +0100

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



reply via email to

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