From: David Hildenbrand <david@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: farman@linux.ibm.com, schnelle@linux.ibm.com, thuth@redhat.com,
pasic@linux.ibm.com, borntraeger@linux.ibm.com,
richard.henderson@linaro.org, iii@linux.ibm.com,
clegoate@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] s390x/pci: add support for guests that request direct mapping
Date: Mon, 9 Dec 2024 23:09:01 +0100 [thread overview]
Message-ID: <7bd2018a-df16-4ede-b7d7-dfdb9cbfc7c0@redhat.com> (raw)
In-Reply-To: <31b6b62b-4656-4ca0-a8ac-99fe4293de45@linux.ibm.com>
On 09.12.24 22:45, Matthew Rosato wrote:
> On 12/9/24 4:01 PM, David Hildenbrand wrote:
>> On 09.12.24 20:29, Matthew Rosato wrote:
>>
>> Hi,
>>
>> Trying to wrap my head around that ... you mention that "pin the entirety of guest memory".
>>
>> Do you mean that we will actually end up longterm pinning all guest RAM in the kernel, similar to what vfio ends up doing?
>
> Yes. Actually, the usecase here is specifically PCI passthrough via vfio-pci on s390. Unlike other platforms, the default s390 approach only pins on-demand and doesn't longterm pin all guest RAM, which is nice from a memory footprint perspective but pays a price via all those guest-2 RPCIT instructions. The goal here is now provide the optional alternative to longterm pin like other platforms.
Okay, thanks for confirming. One more question: who will trigger this
longterm-pinning? Is it vfio?
(the code flow from your code to the pinning code would be nice)
>
>>
>> In that case, it would be incompatible with virtio-balloon (and without modifications with upcoming virtio-mem). Is there already a mechanism in place to handle that -- a call to ram_block_discard_disable() -- or even a way to support coordinated discarding of RAM (e.g., virtio-mem + vfio)?
>
> Good point, should be calling add ram_block_discard_disable(true) when set register + a corresponding (false) during deregister... Will add for v2.
>
> As for supporting coordinated discard, I was hoping to subsequently look at virtio-mem for this.
As long as discarding is blocked for now, we're good. To support it, the
RAMDiscardManager would have to be wired up, similar to vfio.
I think the current way of handling it via
+ IOMMUTLBEvent event = {
+ .type = IOMMU_NOTIFIER_MAP,
+ .entry = {
+ .target_as = &address_space_memory,
+ .translated_addr = 0,
+ .perm = IOMMU_RW,
+ },
+ };
Is probably not ideal: it cannot cope with memory holes (which
virtio-mem would create).
Likely, you'd instead want an address space notifier, and really only
map the memory region sections you get notified about.
There, you can test for RAMDiscardManager and handle it like vfio does.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-12-09 22:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 19:29 [PATCH 0/2] s390x/pci: relax I/O address translation requirement Matthew Rosato
2024-12-09 19:29 ` [PATCH 1/2] s390x/pci: add support for guests that request direct mapping Matthew Rosato
2024-12-09 21:01 ` David Hildenbrand
2024-12-09 21:45 ` Matthew Rosato
2024-12-09 22:09 ` David Hildenbrand [this message]
2024-12-09 23:22 ` Matthew Rosato
2024-12-10 8:58 ` David Hildenbrand
2024-12-13 22:46 ` Matthew Rosato
2024-12-11 11:34 ` Thomas Huth
2024-12-11 14:40 ` Cédric Le Goater
2024-12-11 15:17 ` Matthew Rosato
2024-12-09 19:29 ` [PATCH 2/2] s390x/pci: indicate QEMU supports relaxed translation for passthrough Matthew Rosato
2024-12-11 11:40 ` Thomas Huth
2024-12-12 9:10 ` [PATCH 0/2] s390x/pci: relax I/O address translation requirement Thomas Huth
2024-12-12 14:42 ` Matthew Rosato
2024-12-13 9:07 ` Cédric Le Goater
2024-12-13 9:24 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bd2018a-df16-4ede-b7d7-dfdb9cbfc7c0@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).