All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Dor Laor <dor.laor@qumranet.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: virtio config_ops refactoring
Date: Tue, 06 Nov 2007 17:05:53 -0600	[thread overview]
Message-ID: <4730F351.5060006@us.ibm.com> (raw)
In-Reply-To: <200711070957.44165.rusty__13109.5125260346$1194390035$gmane$org@rustcorp.com.au>

Rusty Russell wrote:
> On Wednesday 07 November 2007 04:48:35 Anthony Liguori wrote:
>> Semantically, find requires that a field have both a type and a length.
>> With the exception of the VIRTQUEUE field used internally by lguest,
>> type is always a unique identifier.  Since virtqueue information is not
>> a required part of the config space, it seems to me that type really
>> should be treated as a unique identifier.
> 
> Hi Anthony,
> 
> 	Not sure I get this.  It is a unique identifier.  You need the length
> to handle unknown fields.

It's not a unique identifier since it can be used for multiple items 
(like it is for virtqueues configs).

>> find_vq also is curious in that it is stateful in it's enumeration.
> 
> Well, they're *all* stateful.  This gives a simple method of knowing what 
> fields the guest understands: it marks the fields as it finds them.  Then it 
> sets the status, which allows the host to know when it's completed 
> configuration reads.

But PCI device configuration is not stateful.  If you care about letting 
the host know what features a guest understands, I think something more 
explicit and stateful should be used.  For instance, a feature register 
that stores a bitmap.

Otherwise, the host has to infer based on what fields that guest has 
read what features the guest actually supports.  That seems error prone 
to me.

> I like enumerating the virtqueues: it's not necessary but it's clearer.
> 
>> This adds seemingly unnecessary complexity.
> 
> I'd be happy for a simpler mechanism...

What do you think of what I proposed?  It seems simpler to me.

Regards,

Anthony Liguori

> Cheers,
> Rusty.


  parent reply	other threads:[~2007-11-06 23:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-06 17:48 virtio config_ops refactoring Anthony Liguori
2007-11-06 22:57 ` Rusty Russell
2007-11-06 23:05   ` Anthony Liguori
2007-11-06 23:05   ` Anthony Liguori [this message]
2007-11-07  6:04     ` [PATCH] " Rusty Russell
2007-11-07  6:04     ` Rusty Russell
2007-11-07 17:30       ` Anthony Liguori
2007-11-07 17:30       ` Anthony Liguori
2007-11-08  2:20         ` Rusty Russell
2007-11-08  2:41           ` Anthony Liguori
2007-11-08 22:24             ` Rusty Russell
2007-11-08 22:33               ` Anthony Liguori
2007-11-08 22:33               ` Anthony Liguori
2007-11-08 22:47                 ` [Lguest] " ron minnich
2007-11-08 22:47                 ` ron minnich
2007-11-08 22:49                   ` Anthony Liguori
2007-11-08 22:49                     ` Anthony Liguori
2007-11-09  0:16                   ` Dor Laor
     [not found]                   ` <4733A6F5.3040202@qumranet.com>
2007-11-09  3:17                     ` Anthony Liguori
2007-11-09  3:17                     ` Anthony Liguori
2007-11-09 11:54                 ` Rusty Russell
2007-11-09 11:54                 ` Rusty Russell
2007-11-09 23:45                   ` Anthony Liguori
2007-11-09 23:45                   ` Anthony Liguori
2007-11-10  7:58                     ` Rusty Russell
2007-11-10 22:08                       ` Anthony Liguori
2007-11-10 22:08                       ` Anthony Liguori
2007-11-10  7:58                     ` Rusty Russell
2007-11-08 22:24             ` Rusty Russell
2007-11-08  2:41           ` Anthony Liguori
2007-11-08  2:20         ` Rusty Russell
2007-11-06 22:57 ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2007-11-06 17:48 Anthony Liguori

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=4730F351.5060006@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=dor.laor@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --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 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.