[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDev
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice |
Date: |
Mon, 23 Apr 2018 18:35:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 23.04.2018 17:32, Pankaj Gupta wrote:
>
> Hi Igor,
>
>>
>>> Right now we can only map PCDIMM/NVDIMM into guest address space. In the
>>> future, we might want to do the same for virtio devices - e.g.
>>> virtio-pmem or virtio-mem. Especially, they should be able to live side
>>> by side to each other.
>>>
>>> E.g. the virto based memory devices regions will not be exposed via ACPI
>>> and friends. They will be detected just like other virtio devices and
>>> indicate the applicable memory region. This makes it possible to also use
>>> them on architectures without memory device detection support (e.g. s390x).
>>>
>>> Let's factor out the memory device code into a MemoryDevice interface.
>> A couple of high level questions as relevant code is not here:
>>
>> 1. what would hotplug/unplug call chain look like in case of virtio-pmem
>> device
>> (reason I'm asking is that pmem being PCI device would trigger
>> PCI bus hotplug controller and then it somehow should piggyback
>> to Machine provided hotplug handlers, so I wonder what kind of
>> havoc it would cause on hotplug infrastructure)
>
> For first phase we are using 'virtio-pmem' as cold added devices. AFAIU
> 'VirtioDeviceClass' being parent class and 'hotplug/unplug' methods
> implemented
> for virtio-pmem device. So, pci bus hotplug/unplug should call the
> corresponding
> functions?
>
>>
>> 2. why not use PCI bar mapping mechanism to do mapping since pmem is PCI
>> device?
>
> I think even we use if as PCI BAR mapping with PCI we still need free guest
> physical
> address to provide to VM for mapping the memory range. For that there needs
> to
> be coordination between PCDIMM and VIRTIO pci device? Also, if we use RAM
> from QEMU
> address space tied to big region(system_memory) memory accounting gets easier
> and at single place.
>
> Honestly speaking I don't think there will be much difference between the two
> approaches? unless
> I am missing something important?
The difference by gluing virtio devices to architecture specific
technologies will be unnecessary complicated. (my humble opinion)
--
Thanks,
David / dhildenb
Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, Pankaj Gupta, 2018/04/22
Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, Igor Mammedov, 2018/04/23
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, David Hildenbrand, 2018/04/23
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, Pankaj Gupta, 2018/04/23
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice,
David Hildenbrand <=
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, Igor Mammedov, 2018/04/24
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, David Hildenbrand, 2018/04/24
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, Igor Mammedov, 2018/04/25
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, David Hildenbrand, 2018/04/25
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 0/3] pc-dimm: factor out MemoryDevice, David Hildenbrand, 2018/04/25