All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@au1.ibm.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>
Cc: virtio-dev@lists.oasis-open.org,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian@bromium.com, Anthony Liguori <anthony@codemonkey.ws>,
	sasha.levin@oracle.com, xen-devel@lists.xenproject.org
Subject: Re: VIRTIO - compatibility with different virtualization solutions
Date: Tue, 25 Feb 2014 11:03:24 +1030	[thread overview]
Message-ID: <87y51058vf.fsf__8294.64352359555$1393292385$gmane$org@rustcorp.com.au> (raw)
In-Reply-To: <20140221150107.GG15905@phenom.dumpdata.com>

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:
> On Fri, Feb 21, 2014 at 10:05:06AM +0000, Wei Liu wrote:
>> On Thu, Feb 20, 2014 at 06:50:59PM -0800, Anthony Liguori wrote:
>> > The standard should say, "physical address"
>
> This conversation is heading towards - implementation needs it - hence lets
> make the design have it. Which I am OK with - but if we are going that
> route we might as well call this thing 'my-pony-number' because I think
> each hypervisor will have a different view of it.
>
> Some of them might use a physical address with some flag bits on it.
> Some might use just physical address.
>
> And some might want an 32-bit value that has no correlation to to physical
> nor virtual addresses.

True, but if the standard doesn't define what it is, it's not a standard
worth anything.  Xen is special because it's already requiring guest
changes; it's a platform in itself and so can be different from
everything else.  But it still needs to be defined.

At the moment, anything but guest-phys would not be compliant.  That's a
Good Thing if we simply don't know the best answer for Xen; we'll adjust
the standard when we do.

Cheers,
Rusty.

  reply	other threads:[~2014-02-25  1:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 13:23 VIRTIO - compatibility with different virtualization solutions Daniel Kiper
2014-02-19  0:26 ` Rusty Russell
     [not found] ` <87vbwcaqxe.fsf@rustcorp.com.au>
2014-02-19  4:42   ` Anthony Liguori
2014-02-20  1:31     ` Rusty Russell
     [not found]     ` <87ha7ubme0.fsf@rustcorp.com.au>
2014-02-20 12:28       ` Stefano Stabellini
2014-02-20 20:28       ` Daniel Kiper
2014-02-21  2:50       ` Anthony Liguori
2014-02-21 10:05         ` Wei Liu
2014-02-21 15:01           ` Konrad Rzeszutek Wilk
2014-02-25  0:33             ` Rusty Russell [this message]
     [not found]             ` <87y51058vf.fsf@rustcorp.com.au>
2014-02-25 21:09               ` Konrad Rzeszutek Wilk
2014-02-19 10:09   ` Ian Campbell
2014-02-20  7:48     ` Rusty Russell
     [not found]     ` <8761oab4y7.fsf@rustcorp.com.au>
2014-02-20 20:37       ` Daniel Kiper
     [not found]       ` <20140220203704.GG3441@olila.local.net-space.pl>
2014-02-21  0:54         ` [virtio-dev] " Rusty Russell
     [not found]         ` <8761o99tft.fsf@rustcorp.com.au>
2014-02-21  3:00           ` Anthony Liguori
2014-02-25  0:40             ` Rusty Russell
     [not found]             ` <87vbw458jr.fsf@rustcorp.com.au>
2014-02-25 21:12               ` Konrad Rzeszutek Wilk
2014-02-26  9:38               ` Ian Campbell
2014-02-21 10:21           ` Wei Liu
2014-02-21 15:11           ` Konrad Rzeszutek Wilk
2014-03-03  5:52             ` Rusty Russell
     [not found]             ` <87ppm325i6.fsf@rustcorp.com.au>
2014-03-04 23:16               ` Michael S. Tsirkin
2014-02-19 10:11   ` Ian Campbell
2014-03-10  7:54 ` Is: Wrap-up Was: " Daniel Kiper
     [not found] ` <20140310075423.GE31874@olila.local.net-space.pl>
2014-03-10 11:19   ` Fabio Fantoni
2014-03-11 14:29     ` Ian Campbell
     [not found] <mailman.9276.1392977438.24322.xen-devel@lists.xen.org>
2014-02-21 16:41 ` Andres Lagar-Cavilla

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='87y51058vf.fsf__8294.64352359555$1393292385$gmane$org@rustcorp.com.au' \
    --to=rusty@au1.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=daniel.kiper@oracle.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian@bromium.com \
    --cc=konrad.wilk@oracle.com \
    --cc=sasha.levin@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.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.