From: Gregory Haskins <ghaskins@novell•com>
To: Avi Kivity <avi@redhat•com>
Cc: linux-kernel@vger•kernel.org, agraf@suse•de,
pmullaney@novell•com, pmorreale@novell•com,
anthony@codemonkey•ws, rusty@rustcorp•com.au,
netdev@vger•kernel.org, kvm@vger•kernel.org
Subject: Re: [RFC PATCH 01/17] shm-signal: shared-memory signals
Date: Tue, 31 Mar 2009 16:58:31 -0400 [thread overview]
Message-ID: <49D283F7.7030508@novell.com> (raw)
In-Reply-To: <49D280C0.8010802@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4762 bytes --]
Avi Kivity wrote:
> Gregory Haskins wrote:
>> This interface provides a bidirectional shared-memory based signaling
>> mechanism. It can be used by any entities which desire efficient
>> communication via shared memory. The implementation details of the
>> signaling are abstracted so that they may transcend a wide variety
>> of locale boundaries (e.g. userspace/kernel, guest/host, etc).
>>
>> The shm_signal mechanism supports event masking as well as spurious
>> event delivery mitigation.
>> +
>> +/*
>> + *---------
>> + * The following structures represent data that is shared across
>> boundaries
>> + * which may be quite disparate from one another (e.g. Windows vs
>> Linux,
>> + * 32 vs 64 bit, etc). Therefore, care has been taken to make sure
>> they
>> + * present data in a manner that is independent of the environment.
>> + *-----------
>> + */
>> +
>> +#define SHM_SIGNAL_MAGIC 0x58fa39df
>> +#define SHM_SIGNAL_VER 1
>> +
>> +struct shm_signal_irq {
>> + __u8 enabled;
>> + __u8 pending;
>> + __u8 dirty;
>> +};
>>
>
> Some ABIs may choose to pad this, suggest explicit padding.
Yeah, good idea. What is the official way to do this these days? Are
GCC pragmas allowed?
>
>> +
>> +enum shm_signal_locality {
>> + shm_locality_north,
>> + shm_locality_south,
>> +};
>> +
>> +struct shm_signal_desc {
>> + __u32 magic;
>> + __u32 ver;
>> + struct shm_signal_irq irq[2];
>> +};
>>
>
> Similarly, this should be padded to 0 (mod 8).
Ack
>
> Instead of versions, I prefer feature flags which can be independently
> enabled or disabled.
Totally agreed. If you look, most of the ABI has a type of "NEGCAP"
(negotiate capabilities) feature. The version number is a contingency
plan in case I still have to break it for whatever reason. I will
always opt for the feature bits over bumping the version when its
feasible (especially if/when this is actually in the field).
>
>> +
>> +/* --- END SHARED STRUCTURES --- */
>> +
>> +#ifdef __KERNEL__
>> +
>> +#include <linux/interrupt.h>
>> +
>> +struct shm_signal_notifier {
>> + void (*signal)(struct shm_signal_notifier *);
>> +};
>>
>
> This means "->inject() has been called from the other side"?
Yep
>
> (reading below I see this is so. not used to reading well commented
> code... :)
:)
>
>> +
>> +struct shm_signal;
>> +
>> +struct shm_signal_ops {
>> + int (*inject)(struct shm_signal *s);
>> + void (*fault)(struct shm_signal *s, const char *fmt, ...);
>>
>
> Eww. Must we involve strings and printf formats?
This is still somewhat of a immature part of the design. Its supposed
to be used so that by default, its a panic. But on the host side, we
can do something like inject a machine-check. That way malicious/broken
guests cannot (should not? ;) be able to take down the host. Note today
I do not map this to anything other than the default panic, so this
needs some love.
But given the asynchronous nature of the fault, I want to be sure we
have decent accounting to avoid bug reports like "silent MCE kills the
guest" ;) At least this way, we can log the fault string somewhere to
get a clue.
>
>> + void (*release)(struct shm_signal *s);
>> +};
>> +
>> +/*
>> + * signaling protocol:
>> + *
>> + * each side of the shm_signal has an "irq" structure with the
>> following
>> + * fields:
>> + *
>> + * - enabled: controlled by shm_signal_enable/disable() to
>> mask/unmask
>> + * the notification locally
>> + * - dirty: indicates if the shared-memory is dirty or clean.
>> This
>> + * is updated regardless of the enabled/pending state
>> so that
>> + * the state is always accurately tracked.
>> + * - pending: indicates if a signal is pending to the remote locale.
>> + * This allows us to determine if a
>> remote-notification is
>> + * already in flight to optimize spurious
>> notifications away.
>> + */
>>
>
> When you overlay a ring on top of this, won't the ring indexes convey
> the same information as ->dirty?
I agree that the information may be redundant with components of the
broader shm state. However, we need this state at this level of scope
in order to function optimally, so I dont think its a huge deal to have
this here as well. Afterall, the shm_signal library can only assess its
internal state. We would have to teach it how to glean the broader
state through some mechanism otherwise (callback, perhaps), but I don't
think its worth it.
-Greg
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2009-03-31 20:56 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-31 18:42 [RFC PATCH 00/17] virtual-bus Gregory Haskins
2009-03-31 18:42 ` [RFC PATCH 01/17] shm-signal: shared-memory signals Gregory Haskins
2009-03-31 20:44 ` Avi Kivity
2009-03-31 20:58 ` Gregory Haskins [this message]
2009-03-31 21:05 ` Avi Kivity
2009-04-01 12:12 ` Gregory Haskins
2009-04-01 12:24 ` Avi Kivity
2009-04-01 13:57 ` Gregory Haskins
2009-03-31 18:42 ` [RFC PATCH 02/17] vbus: add virtual-bus definitions Gregory Haskins
2009-04-02 16:06 ` Ben Hutchings
2009-04-02 18:13 ` Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 03/17] vbus: add connection-client helper infrastructure Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 04/17] vbus: add bus-registration notifiers Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 05/17] vbus: add a "vbus-proxy" bus model for vbus_driver objects Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 06/17] ioq: Add basic definitions for a shared-memory, lockless queue Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 07/17] ioq: add vbus helpers Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 08/17] venet: add the ABI definitions for an 802.x packet interface Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 09/17] net: Add vbus_enet driver Gregory Haskins
2009-03-31 20:39 ` Stephen Hemminger
2009-04-02 11:43 ` Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 10/17] venet-tap: Adds a "venet" compatible "tap" device to VBUS Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 11/17] venet: add scatter-gather support Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 12/17] venettap: " Gregory Haskins
2009-03-31 18:43 ` [RFC PATCH 13/17] x86: allow the irq->vector translation to be determined outside of ioapic Gregory Haskins
2009-03-31 19:16 ` Alan Cox
2009-03-31 20:02 ` Gregory Haskins
2009-03-31 18:44 ` [RFC PATCH 14/17] kvm: add a reset capability Gregory Haskins
2009-03-31 19:22 ` Avi Kivity
2009-03-31 20:02 ` Gregory Haskins
2009-03-31 20:18 ` Avi Kivity
2009-03-31 20:37 ` Gregory Haskins
2009-03-31 18:44 ` [RFC PATCH 15/17] kvm: add dynamic IRQ support Gregory Haskins
2009-03-31 19:20 ` Avi Kivity
2009-03-31 19:39 ` Gregory Haskins
2009-03-31 20:13 ` Avi Kivity
2009-03-31 20:32 ` Gregory Haskins
2009-03-31 20:59 ` Avi Kivity
2009-03-31 18:44 ` [RFC PATCH 16/17] kvm: Add VBUS support to the host Gregory Haskins
2009-03-31 18:44 ` [RFC PATCH 17/17] kvm: Add guest-side support for VBUS Gregory Haskins
2009-03-31 20:18 ` [RFC PATCH 00/17] virtual-bus Andi Kleen
2009-04-01 12:03 ` Gregory Haskins
2009-04-01 13:23 ` Andi Kleen
2009-04-01 14:19 ` Gregory Haskins
2009-04-01 14:42 ` Gregory Haskins
2009-04-01 17:01 ` Andi Kleen
2009-04-01 18:45 ` Anthony Liguori
2009-04-01 20:40 ` Chris Wright
2009-04-01 21:11 ` Gregory Haskins
2009-04-01 21:28 ` Chris Wright
2009-04-01 22:10 ` Gregory Haskins
2009-04-02 6:00 ` Chris Wright
2009-04-02 3:11 ` Herbert Xu
2009-04-01 21:09 ` Gregory Haskins
2009-04-02 0:29 ` Anthony Liguori
2009-04-02 3:11 ` Gregory Haskins
2009-04-02 6:51 ` Avi Kivity
2009-04-02 8:52 ` Herbert Xu
2009-04-02 9:02 ` Avi Kivity
2009-04-02 9:16 ` Herbert Xu
2009-04-02 9:27 ` Avi Kivity
2009-04-02 9:29 ` Herbert Xu
2009-04-02 9:33 ` Herbert Xu
2009-04-02 9:38 ` Avi Kivity
2009-04-02 9:41 ` Herbert Xu
2009-04-02 9:43 ` Avi Kivity
2009-04-02 9:44 ` Herbert Xu
2009-04-02 11:06 ` Gregory Haskins
2009-04-02 11:59 ` Avi Kivity
2009-04-02 12:30 ` Gregory Haskins
2009-04-02 12:43 ` Avi Kivity
2009-04-02 13:03 ` Gregory Haskins
2009-04-02 12:13 ` Rusty Russell
2009-04-02 12:50 ` Gregory Haskins
2009-04-02 12:52 ` Gregory Haskins
2009-04-02 13:07 ` Avi Kivity
2009-04-02 13:22 ` Gregory Haskins
2009-04-02 13:27 ` Avi Kivity
2009-04-02 14:05 ` Gregory Haskins
2009-04-02 14:50 ` Herbert Xu
2009-04-02 15:00 ` Avi Kivity
2009-04-02 15:40 ` Herbert Xu
2009-04-02 15:57 ` Avi Kivity
2009-04-02 16:09 ` Herbert Xu
2009-04-02 16:54 ` Avi Kivity
2009-04-02 17:06 ` Herbert Xu
2009-04-02 17:17 ` Herbert Xu
2009-04-03 12:25 ` Avi Kivity
2009-04-02 15:10 ` Michael S. Tsirkin
2009-04-03 4:43 ` Jeremy Fitzhardinge
2009-04-02 10:55 ` Gregory Haskins
2009-04-02 11:48 ` Avi Kivity
2009-04-03 10:58 ` Gerd Hoffmann
2009-04-03 11:03 ` Avi Kivity
2009-04-03 11:12 ` Herbert Xu
2009-04-03 11:46 ` Avi Kivity
2009-04-03 11:48 ` Herbert Xu
2009-04-03 11:54 ` Avi Kivity
2009-04-03 11:55 ` Herbert Xu
2009-04-03 12:02 ` Avi Kivity
2009-04-03 13:05 ` Herbert Xu
2009-04-03 11:18 ` Andi Kleen
2009-04-03 11:34 ` Herbert Xu
2009-04-03 11:46 ` Avi Kivity
2009-04-03 11:28 ` Gregory Haskins
2009-04-02 10:46 ` Gregory Haskins
2009-04-02 11:43 ` Avi Kivity
2009-04-02 12:22 ` Gregory Haskins
2009-04-02 12:42 ` Avi Kivity
2009-04-02 12:54 ` Gregory Haskins
2009-04-02 13:08 ` Avi Kivity
2009-04-02 13:36 ` Gregory Haskins
2009-04-02 13:45 ` Avi Kivity
2009-04-02 14:24 ` Gregory Haskins
2009-04-02 14:32 ` Avi Kivity
2009-04-02 14:41 ` Avi Kivity
2009-04-02 14:49 ` Anthony Liguori
2009-04-02 16:09 ` Anthony Liguori
2009-04-02 16:19 ` Avi Kivity
2009-04-02 18:18 ` Anthony Liguori
2009-04-03 1:11 ` Herbert Xu
2009-04-20 18:02 ` Alex Williamson
2009-04-03 12:03 ` Gregory Haskins
2009-04-03 12:15 ` Avi Kivity
2009-04-03 13:13 ` Gregory Haskins
2009-04-03 13:37 ` Avi Kivity
2009-04-03 16:28 ` Gregory Haskins
2009-04-05 10:00 ` Avi Kivity
2009-04-02 3:09 ` Herbert Xu
2009-04-02 6:46 ` Avi Kivity
2009-04-02 8:54 ` Herbert Xu
2009-04-02 9:03 ` Avi Kivity
2009-04-02 9:05 ` Herbert Xu
2009-04-01 20:29 ` Gregory Haskins
2009-04-01 22:23 ` Andi Kleen
2009-04-01 23:05 ` Gregory Haskins
2009-04-01 6:08 ` Rusty Russell
2009-04-01 11:35 ` Gregory Haskins
2009-04-02 1:24 ` Rusty Russell
2009-04-02 2:27 ` Gregory Haskins
2009-04-01 16:10 ` Anthony Liguori
2009-04-05 3:44 ` Rusty Russell
2009-04-05 8:06 ` Avi Kivity
2009-04-05 14:13 ` Anthony Liguori
2009-04-05 16:10 ` Avi Kivity
2009-04-05 16:45 ` Anthony Liguori
2009-04-02 3:15 ` Herbert Xu
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=49D283F7.7030508@novell.com \
--to=ghaskins@novell$(echo .)com \
--cc=agraf@suse$(echo .)de \
--cc=anthony@codemonkey$(echo .)ws \
--cc=avi@redhat$(echo .)com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pmorreale@novell$(echo .)com \
--cc=pmullaney@novell$(echo .)com \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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