|
From: | David Hildenbrand |
Subject: | Re: [PATCH v2 1/2] s390x/pci: add support for guests that request direct mapping |
Date: | Mon, 16 Dec 2024 17:56:24 +0100 |
User-agent: | Mozilla Thunderbird |
On 16.12.24 17:53, Matthew Rosato wrote:
+{ + MachineState *ms = MACHINE(qdev_get_machine()); + + /* + * For direct-mapping we must map the entire guest address space. Rather + * than using an iommu, create a memory region alias that maps GPA X to + * iova X + SDMA. VFIO will handle pinning via its memory listener. + */ + g_autofree char *name = g_strdup_printf("iommu-dm-s390-%04x", + iommu->pbdev->uid); + memory_region_init_alias(&iommu->dm_mr, OBJECT(&iommu->mr), name, ms->ram, + 0, ms->ram_size);Is it a good idea to take the whole machine ram-size here? Could it be better to pass it as qdev property?I think we want all guest RAM, just like ordinary vfio on !s390x without a viommu would do. Matthew, I assume to handle virtio-mem, we would actually pass in here the result from s390_get_memory_limit(), which will cover initial+device RAM, correct? Until then, this would map initial RAM only.Good point. Using s390_get_memory_limit() sounds good to me; That will make v3 of this series dependent on the s390x virtio-mem series but sounds like you're sending that sometime this week anyway.
If my testing is good and there are no further comments, I'll queue it directly (no change to v2) to send it upstream.
So it's probably a good idea to wait with a new series her.
I'll start testing on top of that with something like.. memory_region_init_alias(&iommu->dm_mr, OBJECT(&iommu->mr), name, ms->ram, 0, s390_get_memory_limit(s390ms));
Yes, I think so.We discussed at some point maybe requiring disabling uncoordinated discarding of RAM (virtio-balloon), is that already done implicitly now?
-- Cheers, David / dhildenb
[Prev in Thread] | Current Thread | [Next in Thread] |