From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Gavin Shan" <gshan@redhat.com>, "Peter Xu" <peterx@redhat.com>,
"Pavel Hrdina" <phrdina@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org, jugraham@redhat.com,
shan.gavin@gmail.com, "Alex Williamson" <alex@shazbot.org>,
"David Hildenbrand" <david@kernel.org>
Subject: Re: [PATCH RFCv1] virtio: Inherit max bounce buffer size from bus parent if possible
Date: Thu, 11 Jun 2026 13:02:34 -0400 [thread overview]
Message-ID: <20260611130037-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAFEAcA8vOMd64cCkfCyc1wNbjEY+bnhFPce-V_WbAuXrUnP8cw@mail.gmail.com>
On Thu, Jun 11, 2026 at 05:53:54PM +0100, Peter Maydell wrote:
> On Thu, 11 Jun 2026 at 17:42, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 05:16:09PM +0100, Peter Maydell wrote:
> > > On Thu, 11 Jun 2026 at 16:57, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > Then I'd like to see an example where we have an actual good reason
> > > > to do execute arbitrary width accesses on device RAM when the
> > > > driver does not execute them, please.
> > >
> > > That's the case we started with, with this GPU where the
> > > virtio data structures are in this PCI BAR. We want the
> > > virtio backend to have the freedom to say "I'm just going
> > > to assume the ring buffer etc is in RAM, and I don't need to
> > > care about carefully ensuring that I only do word accesses".
> >
> > virtio backend does not need to assume anything. any spec
> > compliant guest guarantees it. any address given to
> > a virtio device is ram.
>
> OK, but how do we tell if the mmap() PCI BAR we have is RAM
> or not ? Some of them are, some of them aren't...
>
> -- PMM
We don't care? If guest asked a virtio device to access
memory then that memory better support accesses guest
requested, and on virtio that means any width.
--
MST
next prev parent reply other threads:[~2026-06-11 17:03 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 0:18 [PATCH RFCv1] virtio: Inherit max bounce buffer size from bus parent if possible Gavin Shan
2026-06-08 8:55 ` Daniel P. Berrangé
2026-06-08 11:11 ` Gavin Shan
2026-06-08 11:38 ` Daniel P. Berrangé
2026-06-09 2:08 ` Gavin Shan
2026-06-09 16:25 ` Peter Xu
2026-06-10 0:32 ` Gavin Shan
2026-06-10 9:54 ` Pavel Hrdina
2026-06-10 10:55 ` Gavin Shan
2026-06-10 12:12 ` Michael S. Tsirkin
2026-06-10 12:19 ` Gavin Shan
2026-06-10 12:27 ` Michael S. Tsirkin
2026-06-10 13:00 ` Gavin Shan
2026-06-10 13:54 ` Gavin Shan
2026-06-10 14:06 ` Michael S. Tsirkin
2026-06-10 15:36 ` Peter Xu
2026-06-10 16:11 ` Peter Maydell
2026-06-10 16:19 ` Michael S. Tsirkin
2026-06-10 19:10 ` Peter Xu
2026-06-10 21:03 ` Michael S. Tsirkin
2026-06-10 21:27 ` Peter Xu
2026-06-10 21:44 ` Michael S. Tsirkin
2026-06-10 16:18 ` Michael S. Tsirkin
2026-06-11 4:33 ` Gavin Shan
2026-06-11 5:31 ` Michael S. Tsirkin
2026-06-11 6:28 ` Gavin Shan
2026-06-11 6:34 ` Michael S. Tsirkin
2026-06-11 12:33 ` Gavin Shan
2026-06-11 12:48 ` Peter Maydell
2026-06-11 14:10 ` Michael S. Tsirkin
2026-06-11 14:55 ` Peter Maydell
2026-06-11 15:05 ` Michael S. Tsirkin
2026-06-11 15:25 ` Michael S. Tsirkin
2026-06-11 15:29 ` Peter Maydell
2026-06-11 15:57 ` Michael S. Tsirkin
2026-06-11 16:16 ` Peter Maydell
2026-06-11 16:42 ` Michael S. Tsirkin
2026-06-11 16:53 ` Peter Maydell
2026-06-11 17:02 ` Michael S. Tsirkin [this message]
2026-06-11 18:20 ` Peter Xu
2026-06-11 20:52 ` Michael S. Tsirkin
2026-06-11 16:13 ` Michael S. Tsirkin
2026-06-11 6:51 ` Michael S. Tsirkin
2026-06-10 12:23 ` Pavel Hrdina
2026-06-10 14:04 ` Gavin Shan
2026-06-10 14:08 ` Michael S. Tsirkin
2026-06-10 9:49 ` Michael S. Tsirkin
2026-06-10 18:30 ` Stefan Hajnoczi
2026-06-10 21:00 ` Michael S. Tsirkin
2026-06-11 14:20 ` Stefan Hajnoczi
2026-06-11 14:45 ` Michael S. Tsirkin
2026-06-11 15:04 ` Peter Maydell
2026-06-11 15:09 ` Michael S. Tsirkin
2026-06-11 18:37 ` Stefan Hajnoczi
2026-06-11 20:54 ` Michael S. Tsirkin
2026-06-11 1:19 ` Gavin Shan
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=20260611130037-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex@shazbot.org \
--cc=berrange@redhat.com \
--cc=david@kernel.org \
--cc=gshan@redhat.com \
--cc=jugraham@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=phrdina@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shan.gavin@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.