From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
virtio-comment@lists.oasis-open.org,
virtio-dev@lists.oasis-open.org
Subject: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] Re: [PATCH v2 3/3] shared memory: Define mmio registers
Date: Wed, 27 Feb 2019 18:37:29 +0000 [thread overview]
Message-ID: <20190227183728.GL2602@work-vm> (raw)
In-Reply-To: <20190227170612.GE927@stefanha-x1.localdomain>
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> On Wed, Feb 27, 2019 at 02:56:52PM +0100, Cornelia Huck wrote:
> > On Mon, 25 Feb 2019 18:45:06 +0000
> > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> >
> > > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > > On Fri, Feb 22, 2019 at 11:54:33AM +0000, Dr. David Alan Gilbert (git) wrote:
> >
> > > > > + region, as defined by the device for the region selected by
> > > > > + the \field{SHMId} register. Reading from a non-existent
> > > > > + region (i.e. where the ID written to \field{SHMId} is unused)
> > > > > + results in a length of -1.
> > > >
> > > > -1 is used to indicate the absence of a region, does 0 have a meaning?
> > >
> > > No, I'd be happy to switch; although this does lead to another question;
> > > what happens on an older virtio-mmio implementation when a device
> > > tries to read these registers to detect if the region exists?
> >
> > You probably mean that the driver is reading, right? Not sure if we
> > ever specified what happens if a driver interacts with a register that
> > was not specified when the device was written... maybe we need to bump
> > the device version number? But that would break old drivers if they get
> > a 3 but expected a 2.
>
> I see the rationale for using 0xffffffff since that's what loads produce
> when there is nothing at the memory address. It would be good to
> document that :).
Is that actually defined that we get 0xffffffff? - in which case
yes I'd add it as a reasoning; but I hadn't realised it was actually
defined anywhere.
> Incrementing the version as Cornelia suggested is cleaner though, if
> existing drivers handle that gracefully. Or maybe a transport feature
> bit (are they in short supply?).
We do have transport feature bits for other transports don't we, and
they can overlap those.
Dave
> Stefan
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2019-02-27 18:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 11:54 [virtio-comment] [PATCH v2 0/3] Large shared memory regions Dr. David Alan Gilbert (git)
2019-02-22 11:54 ` [virtio-comment] [PATCH v2 1/3] shared memory: Define " Dr. David Alan Gilbert (git)
2019-02-22 12:48 ` [virtio-comment] " Cornelia Huck
2019-02-25 16:37 ` Stefan Hajnoczi
2019-02-26 15:11 ` [virtio-comment] Re: [virtio-dev] " Dr. David Alan Gilbert
2019-02-26 15:40 ` Halil Pasic
2019-02-26 15:43 ` Cornelia Huck
2019-03-04 12:46 ` Dr. David Alan Gilbert
2019-02-22 11:54 ` [virtio-comment] [PATCH v2 2/3] shared memory: Define PCI capability Dr. David Alan Gilbert (git)
2019-02-22 12:50 ` [virtio-comment] " Cornelia Huck
2019-02-22 11:54 ` [virtio-comment] [PATCH v2 3/3] shared memory: Define mmio registers Dr. David Alan Gilbert (git)
2019-02-25 16:50 ` [virtio-comment] " Stefan Hajnoczi
2019-02-25 18:45 ` Dr. David Alan Gilbert
2019-02-27 13:56 ` Cornelia Huck
2019-02-27 17:06 ` Stefan Hajnoczi
2019-02-27 18:37 ` Dr. David Alan Gilbert [this message]
2019-02-27 18:52 ` [virtio-comment] Re: [virtio-dev] " Dr. David Alan Gilbert
2019-02-27 13:50 ` Cornelia Huck
2019-02-27 18:33 ` [virtio-comment] Re: [virtio-dev] " Dr. David Alan Gilbert
2019-03-05 15:47 ` [virtio-comment] [PATCH v2 0/3] Large shared memory regions Frank Yang
2019-06-17 18:38 ` Michael S. Tsirkin
2019-06-17 18:59 ` Frank Yang
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=20190227183728.GL2602@work-vm \
--to=dgilbert@redhat.com \
--cc=cohuck@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/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.