[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options |
Date: |
Tue, 2 Mar 2010 11:57:57 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
On Mon, Mar 01, 2010 at 03:54:00PM -0600, Anthony Liguori wrote:
> On 03/01/2010 01:27 PM, Michael S. Tsirkin wrote:
>> On Sun, Feb 28, 2010 at 10:39:21PM +0000, Paul Brook wrote:
>>
>>>> I'm sympathetic to your arguments though. As qemu is today, the above
>>>> is definitely the right thing to do. But ram is always ram and ram
>>>> always has a fixed (albeit non-linear) mapping within a guest.
>>>>
>>> I think this assumption is unsafe. There are machines where RAM mappings can
>>> change. It's not uncommon for a chip select (i.e. physical memory address
>>> region) to be switchable to several different sources, one of which may be
>>> RAM. I'm pretty sure this functionality is present (but not actually
>>> implemented) on some of the current qemu targets.
>>>
>>> I agree that changing RAM mappings under an active DMA is a fairly suspect
>>> thing to do. However I think we need to avoid cache mappings between
>>> separate
>>> DMA transactions i.e. when the guest can know that no DMA will occur, and
>>> safely remap things.
>>>
>>> I'm also of the opinion that virtio devices should behave the same as any
>>> other device. i.e. if you put a virtio-net-pci device on a PCI bus behind an
>>> IOMMU, then it should see the same address space as any other PCI device in
>>> that location.
>>>
>> It already doesn't. virtio passes physical memory addresses
>> to device instead of DMA addresses.
>>
>
> That's technically a bug.
>
>>> Apart from anything else, failure to do this breaks nested
>>> virtualization.
>>>
>> Assigning PV device in nested virtualization? It could work, but not
>> sure what the point would be.
>>
>
> It misses the point really.
>
> vhost-net is not a device model and it shouldn't have to care about
> things like PCI IOMMU. If we did ever implement a PCI IOMMU, then we
> would perform ring translation (or not use vhost-net).
>
> Regards,
>
> Anthony Liguori
Right.
>>> While qemu doesn't currently implement an IOMMU, the DMA
>>> interfaces have been designed to allow it.
>>>
>>>
>>>> void cpu_ram_add(target_phys_addr_t start, ram_addr_t size);
>>>>
>>> We need to support aliased memory regions. For example the ARM RealView
>>> boards
>>> expose the first 256M RAM at both address 0x0 and 0x70000000. It's also
>>> common
>>> for systems to create aliases by ignoring certain address bits. e.g. each
>>> sim
>>> slot is allocated a fixed 256M region. Populating that slot with a 128M
>>> stick
>>> will cause the contents to be aliased in both the top and bottom halves of
>>> that region.
>>>
>>> Paul
>>>
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Michael S. Tsirkin, 2010/03/01
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Anthony Liguori, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Paul Brook, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Anthony Liguori, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Paul Brook, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Anthony Liguori, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Paul Brook, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Michael S. Tsirkin, 2010/03/02
- [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Anthony Liguori, 2010/03/02
- Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Marcelo Tosatti, 2010/03/02
Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options, Marcelo Tosatti, 2010/03/02