[Qemu-devel] physical memory address in guest (from his point of view)

[Qemu-devel] physical memory address in guest (from his point of view)

[Catalin Vasile]

Does a physical memory address in a guest points to the same memory as qemu?
For example: if I have a physical pointer 0x34 in the guest, does it
point to the same location that qemu points with 0x34 address?

Re: [Qemu-devel] physical memory address in guest (from his point of view)

[Paolo Bonzini]

On 24/04/2015 10:46, Catalin Vasile wrote:
> Does a physical memory address in a guest points to the same memory as qemu?
> For example: if I have a physical pointer 0x34 in the guest, does it
> point to the same location that qemu points with 0x34 address?

No.  QEMU converts guest pointers (which are just uint64_t) to host
pointers using address_space_map/address_space_unmap.

Paolo

Re: [Qemu-devel] physical memory address in guest (from his point of view)

[Catalin Vasile]

On Fri, Apr 24, 2015 at 12:05 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 24/04/2015 10:46, Catalin Vasile wrote:
>> Does a physical memory address in a guest points to the same memory as qemu?
>> For example: if I have a physical pointer 0x34 in the guest, does it
>> point to the same location that qemu points with 0x34 address?
>
> No.  QEMU converts guest pointers (which are just uint64_t) to host
> pointers using address_space_map/address_space_unmap.
>
> Paolo
That being said. Does a message that passes from guest to a backend
need to pass through qemu everytime?
I'm trying to understand how virtio virtqueues work. Namely I'm trying
to pass as data itself a pointer in which the backend will write,
namely use copy_to_user() if the backend is a kernel module.

Re: [Qemu-devel] physical memory address in guest (from his point of view)

[Paolo Bonzini]

On 24/04/2015 12:22, Catalin Vasile wrote:
> > > Does a physical memory address in a guest points to the same memory as qemu?
> > > For example: if I have a physical pointer 0x34 in the guest, does it
> > > point to the same location that qemu points with 0x34 address?
> >
> > No.  QEMU converts guest pointers (which are just uint64_t) to host
> > pointers using address_space_map/address_space_unmap.
>
> That being said. Does a message that passes from guest to a backend
> need to pass through qemu everytime?
> I'm trying to understand how virtio virtqueues work. Namely I'm trying
> to pass as data itself a pointer in which the backend will write,
> namely use copy_to_user() if the backend is a kernel module.

vhost provides the infrastructure to do the same thing as
address_space_map/unmap.

Passing pointers inside a data buffer would be very weird for virtio
devices.  The way you do it typically, is that you pass a one descriptor
corresponding to a request or response header, and one or more
descriptors for the data buffers.

Paolo

Re: [Qemu-devel] physical memory address in guest (from his point of view)

[Peter Maydell]

On 24 April 2015 at 09:46, Catalin Vasile <catalinvasile92@gmail.com> wrote:
> Does a physical memory address in a guest points to the same memory as qemu?
> For example: if I have a physical pointer 0x34 in the guest, does it
> point to the same location that qemu points with 0x34 address?

As an additional point to Paolo's answer, consider that:
 (1) a guest physical address alone may not be sufficient to identify
the host memory/device [consider ARM TrustZone where you also need
to know the Secure/NonSecure attribute]
 (2) a guest physical address may not map to anything on the host
 (3) a guest physical address may map to an emulated device, not
host RAM
 (4) multiple guest physical addresses may map to a single host
RAM address [if the RAM is aliased to multiple physaddrs]
 (5) host memory that is part of the machine model may not be
mapped to any guest physical address [consider a device with a
block of "ram" accessed via set-address/write-data commands, or
a PCI device with a BAR that has been temporarily unmapped by the guest]

There are a lot of odd cases that the memory system infrastructure
deals with for you...

-- PMM