From: Avi Kivity <avi@redhat.com>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH v4 1/3] Device specification for shared memory PCI device
Date: Mon, 12 Apr 2010 23:34:28 +0300 [thread overview]
Message-ID: <4BC383D4.1090002@redhat.com> (raw)
In-Reply-To: <1270680720-8457-2-git-send-email-cam@cs.ualberta.ca>
On 04/08/2010 01:51 AM, Cam Macdonell wrote:
(sorry about the late review)
> +
> +Regular Interrupts
> +------------------
> +
> +If regular interrupts are used (due to either a guest not supporting MSI or the
> +user specifying not to use them on startup) then the value written to the lower
> +16-bits of the Doorbell register results is arbitrary and will trigger an
> +interrupt in the destination guest.
>
Does the value written show up in the status register? If yes, it can
get overwritten by other interrupts. If not, the lower 16 bits should
be reserved to the value 1 for future expansion. Basically it means
that the pci interrupt is equivalent to to vector 1.
> +
> +An interrupt is also generated when a new guest accesses the shared memory
> +region. A status of (2^32 - 1) indicates that a new guest has joined.
>
Suggest making this a bitfield, define bit 0 as 'at least some other
machine has signalled you' and bit 1 as 'at least one other machine has
joined'.
> +
> +Message Signalled Interrupts
> +----------------------------
> +
> +A ivshmem device may support multiple MSI vectors. If so, the lower 16-bits
> +written to the Doorbell register must be between 1 and the maximum number of
> +vectors the guest supports. The lower 16 bits written to the doorbell is the
> +MSI vector that will be raised in the destination guest. The number of MSI
> +vectors can vary but it is set when the VM is started, however vector 0 is
> +used to notify that a new guest has joined. Guests should not use vector 0 for
> +any other purpose.
>
Come to think about it, the guest has joined is actually pointless.
Since it hasn't initialized yet you can't talk to it. So it's best to
leave it completely to the application, which can initialize shared
memory and start sending interrupts. An application defined protocol
can handle joining.
How is initialization performed? I guess we can define memory to start
zeroed and let participants compete to acquire a lock.
Need to document the mask register.
Do we want an interrupt on a guest leaving? Let's not complicate things.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2010-04-12 20:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 22:51 [Qemu-devel] [PATCH v4 0/3] PCI Shared memory device Cam Macdonell
2010-04-07 22:51 ` [Qemu-devel] [PATCH v4 1/3] Device specification for shared memory PCI device Cam Macdonell
2010-04-07 22:51 ` [Qemu-devel] [PATCH v4 2/3] Support adding a file to qemu's ram allocation Cam Macdonell
2010-04-07 22:52 ` [Qemu-devel] [PATCH v4 3/3] Inter-VM shared memory PCI device Cam Macdonell
2010-04-12 20:56 ` [Qemu-devel] " Avi Kivity
2010-04-14 23:30 ` Cam Macdonell
2010-04-15 8:33 ` Avi Kivity
2010-04-12 20:38 ` [Qemu-devel] Re: [PATCH v4 2/3] Support adding a file to qemu's ram allocation Avi Kivity
2010-04-07 23:00 ` [Qemu-devel] [PATCH v4] Shared memory uio_pci driver Cam Macdonell
2010-04-12 20:57 ` [Qemu-devel] " Avi Kivity
2010-04-23 17:45 ` Cam Macdonell
2010-04-24 9:28 ` Avi Kivity
2010-04-12 20:34 ` Avi Kivity [this message]
2010-04-12 21:11 ` [Qemu-devel] Re: [PATCH v4 1/3] Device specification for shared memory PCI device Cam Macdonell
2010-04-12 21:17 ` [Qemu-devel] Re: [PATCH v4 0/3] PCI Shared memory device Michael S. Tsirkin
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=4BC383D4.1090002@redhat.com \
--to=avi@redhat.com \
--cc=cam@cs.ualberta.ca \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.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 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).