linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: gnomes@lxorguk.ukuu.org.uk (One Thousand Gnomes)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] xen/block: Correctly define structures in public headers on ARM32 and ARM64
Date: Tue, 3 Dec 2013 16:32:28 +0000	[thread overview]
Message-ID: <20131203163228.3313dff8@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <529E04AB.5060304@linaro.org>

> > How does the patch ensure new kernels on existing hypervisor versions
> > don't break ?
> 
> As Ian said on the thread "xen-block: correctly define structures in
> public headers" (see thread https://lkml.org/lkml/2013/12/3/155), the
> ABI is not yet fixed for ARM.

And if you are one of the existing users that helps how ?

> > 
> > What is the failure case given the alignment change seems potentially to
> > produce valid but incorrect I/O requests - can it cause corruption ?
> 
> The request ID will likely be wrong, so the guest won't accept the
> request. It should not corrupt the block device.

"Would likely" 

That seems joyously confident.

So at the very least your guest should deliberately issue a request which
will error if the ABI version mismatches, and at that point you know
which ABI to use so the guest can keep compatibility trivially.

> > It seems to me you should be defining
> > 
> > struct blkif_request_rw_v2
> > 
> > and using the correct version according to which API the hypervisor
> > requires, not just breaking it.
> 
> This API doesn't involve the hypervisor. It's only a way to talk between
> DOM0 and a guest. Without this change you will break compatibility with
> other OSes.

With this change you break compatibility between the existing OS's,new
guests and old DOM0 and vice versa.

If a request in old format is guaranteed to error in new format (or you
can construct one that will) then you can trivially support both APIs on
the guest side at least for a while. That will avoid regressions when
people mix versions and also mean you've got a much better ability to
find a bug if stuff breaks as you won't have to switch guest and dom0
together when debugging.

Alan

  reply	other threads:[~2013-12-03 16:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03 15:40 [PATCH v2] xen/block: Correctly define structures in public headers on ARM32 and ARM64 Julien Grall
2013-12-03 16:00 ` One Thousand Gnomes
2013-12-03 16:19   ` Julien Grall
2013-12-03 16:32     ` One Thousand Gnomes [this message]
2013-12-03 16:41       ` Ian Campbell
2013-12-03 17:03         ` One Thousand Gnomes
2013-12-03 18:03           ` Konrad Rzeszutek Wilk
2013-12-03 17:10 ` David Vrabel
2013-12-03 18:01   ` Konrad Rzeszutek Wilk
2013-12-12 14:19 ` [Xen-devel] " Ian Campbell
2013-12-12 15:11   ` Roger Pau Monné

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=20131203163228.3313dff8@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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).