From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Anthony Liguori <aliguori@us.ibm.com>,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Stefan Hajnoczi <stefanha@redhat.com>,
KONRAD Frederic <fred.konrad@greensocs.com>
Subject: Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR
Date: Wed, 29 May 2013 15:37:11 +0300 [thread overview]
Message-ID: <20130529123711.GU4472@redhat.com> (raw)
In-Reply-To: <51A5F470.4070407@redhat.com>
On Wed, May 29, 2013 at 02:28:32PM +0200, Paolo Bonzini wrote:
> Il 29/05/2013 14:16, Michael S. Tsirkin ha scritto:
> >>>> > >> If you really want to use offsetof like this you're
> >>>> > >> going to need to decorate the structs with QEMU_PACKED.
> >> >
> >>> > > Nope.
> >>> > > These structs are carefully designed not to have any padding.
> >> >
> >> > ...on every compiler and OS combination that QEMU builds for?
> > Yes. All the way back to EGCS and before.
> > GCC has been like this for many many years.
>
> I would still prefer to have QEMU_PACKED (or __attribute((__packed__))
> in the kernel).
>
> >>> > > And if there was a bug and there was some padding, we still
> >>> > > can't fix it with PACKED because this structure
> >>> > > is used to interact with the guest code which does not
> >>> > > have the packed attribute.
> >> >
> >> > The guest code has to use a set of structure offsets and
> >> > sizes which is fixed by the virtio ABI -- how it implements
> >> > this is up to the guest (and if it misimplements it that is
> >> > a guest bug and not our problem).
>
> On the other hand, encouraging both userspace and guest to reuse a
> single set of headers means that the bad offset becomes a spec bug more
> than a guest bug.
Heh
> > Deviating from driver in random ways is an endless source
> > of hard to debug issues, and it's a very practical
> > consideration because virtio spec is constantly
> > being extended (unlike hardware which is mostly fixed).
>
> Agreed---but the driver should use __attribute__((__packed__)) too.
>
> Paolo
For these specific structures I don't mind, we never dereference them
anyway. If you do dereference a structure, using packed is generally
a mistake. In particular because GCC generates code that is
much slower.
You can also get nasty surprises e.g.
struct foo {
char a;
int b;
} __attribute__((packed));
struct foo foo;
int *a = &foo.a;
Last line compiles fine but isn't legal C.
So I think there are two cases with packed:
1. it does not change logical behaviour but results in bad code
generated
2. it does change logical behaviour and leads to unsafe code
There aren't many good reasons to use packed: if you
must treat unaligned data, best to use constants.
--
MST
next prev parent reply other threads:[~2013-05-29 12:37 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 16:03 [PATCH RFC] virtio-pci: new config layout: using memory BAR Michael S. Tsirkin
2013-05-28 17:15 ` Anthony Liguori
[not found] ` <87bo7vvxej.fsf@codemonkey.ws>
2013-05-28 17:32 ` Michael S. Tsirkin
2013-05-28 17:43 ` Paolo Bonzini
2013-05-29 2:02 ` Laszlo Ersek
2013-05-29 4:33 ` Rusty Russell
[not found] ` <87mwremmm8.fsf@rustcorp.com.au>
2013-05-29 7:27 ` Paolo Bonzini
2013-05-29 8:05 ` Michael S. Tsirkin
2013-05-29 10:07 ` Laszlo Ersek
2013-05-28 18:53 ` Anthony Liguori
2013-05-28 19:27 ` Michael S. Tsirkin
2013-05-29 4:31 ` Rusty Russell
2013-05-29 8:24 ` Michael S. Tsirkin
2013-05-29 8:52 ` Paolo Bonzini
2013-05-29 9:00 ` Peter Maydell
2013-05-29 10:08 ` Michael S. Tsirkin
2013-05-29 10:53 ` Peter Maydell
2013-05-29 12:16 ` Michael S. Tsirkin
2013-05-29 12:28 ` Paolo Bonzini
2013-05-29 12:37 ` Michael S. Tsirkin [this message]
2013-05-29 12:52 ` Anthony Liguori
2013-05-29 13:24 ` Michael S. Tsirkin
2013-05-29 13:35 ` Peter Maydell
2013-05-29 13:41 ` Paolo Bonzini
2013-05-29 14:02 ` Michael S. Tsirkin
2013-05-29 14:18 ` Anthony Liguori
2013-05-30 7:43 ` Michael S. Tsirkin
2013-05-29 14:16 ` Anthony Liguori
[not found] ` <8761y1q3aw.fsf@codemonkey.ws>
2013-05-29 14:30 ` Michael S. Tsirkin
2013-05-29 14:32 ` Paolo Bonzini
2013-05-29 14:52 ` Michael S. Tsirkin
2013-05-29 14:55 ` Anthony Liguori
[not found] ` <87k3mhkf7o.fsf@codemonkey.ws>
2013-05-29 16:12 ` Michael S. Tsirkin
2013-05-29 18:16 ` Michael S. Tsirkin
2013-05-30 3:58 ` Rusty Russell
2013-05-30 5:55 ` Michael S. Tsirkin
2013-05-30 7:55 ` Michael S. Tsirkin
2013-06-03 0:17 ` Rusty Russell
2013-05-30 13:53 ` Anthony Liguori
2013-05-30 14:01 ` Michael S. Tsirkin
2013-06-03 0:26 ` Rusty Russell
2013-06-03 10:11 ` Michael S. Tsirkin
2013-06-04 5:31 ` Rusty Russell
2013-06-04 6:42 ` Michael S. Tsirkin
2013-06-05 7:19 ` Rusty Russell
2013-06-05 10:22 ` Michael S. Tsirkin
2013-06-05 12:59 ` Anthony Liguori
2013-06-05 14:09 ` Michael S. Tsirkin
2013-06-05 15:08 ` Anthony Liguori
2013-06-05 15:19 ` Michael S. Tsirkin
2013-06-05 15:46 ` Anthony Liguori
[not found] ` <87bo7ktvaw.fsf@codemonkey.ws>
2013-06-05 16:20 ` Michael S. Tsirkin
2013-06-05 18:57 ` Anthony Liguori
2013-06-05 19:43 ` Michael S. Tsirkin
2013-06-05 19:52 ` Michael S. Tsirkin
2013-06-05 20:45 ` Anthony Liguori
2013-06-05 21:15 ` H. Peter Anvin
2013-06-05 21:15 ` Michael S. Tsirkin
2013-06-05 20:42 ` Anthony Liguori
2013-06-05 21:14 ` Michael S. Tsirkin
2013-06-05 21:53 ` Anthony Liguori
[not found] ` <87d2s0mdh8.fsf@codemonkey.ws>
2013-06-05 22:19 ` Benjamin Herrenschmidt
2013-06-05 22:53 ` Anthony Liguori
2013-06-05 23:27 ` Benjamin Herrenschmidt
2013-06-05 19:54 ` Michael S. Tsirkin
2013-06-06 3:42 ` Rusty Russell
2013-06-06 14:59 ` Anthony Liguori
2013-06-07 1:58 ` Rusty Russell
2013-06-07 8:25 ` Peter Maydell
2013-06-05 21:10 ` H. Peter Anvin
2013-06-05 21:17 ` Michael S. Tsirkin
2013-06-05 21:50 ` Anthony Liguori
2013-06-05 21:55 ` H. Peter Anvin
2013-06-05 22:08 ` Anthony Liguori
2013-06-05 23:07 ` H. Peter Anvin
2013-06-06 0:41 ` Anthony Liguori
2013-06-06 6:34 ` Gleb Natapov
2013-06-06 13:53 ` H. Peter Anvin
2013-06-06 15:02 ` Anthony Liguori
2013-06-06 15:06 ` Gerd Hoffmann
2013-06-06 15:10 ` Gleb Natapov
2013-06-06 15:19 ` H. Peter Anvin
2013-06-06 15:22 ` Gerd Hoffmann
2013-07-08 4:25 ` Kevin O'Connor
[not found] ` <871u8fp9jd.fsf@codemonkey.ws>
2013-06-07 11:30 ` Gleb Natapov
2013-06-11 7:10 ` Michael S. Tsirkin
2013-06-11 7:53 ` Gleb Natapov
2013-06-11 8:02 ` Michael S. Tsirkin
2013-06-11 8:03 ` Gleb Natapov
2013-06-11 8:19 ` Michael S. Tsirkin
2013-06-11 8:22 ` Gleb Natapov
2013-06-11 8:30 ` Michael S. Tsirkin
2013-06-11 8:32 ` Gleb Natapov
2013-06-11 8:04 ` Michael S. Tsirkin
2013-06-06 8:02 ` 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=20130529123711.GU4472@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=fred.konrad@greensocs.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.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).