public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: lguest <lguest@ozlabs.org>,
	linux-kernel@vger.kernel.org, Dor Laor <dor.laor@qumranet.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] virtio config_ops refactoring
Date: Fri, 09 Nov 2007 17:45:38 -0600	[thread overview]
Message-ID: <4734F122.8000102@codemonkey.ws> (raw)
In-Reply-To: <200711092254.08099.rusty@rustcorp.com.au>

Rusty Russell wrote:
> On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
>   
>> switch (addr) {
>> case VIRTIO_BLK_CONFIG_MAX_SEG:
>>    return vdev->max_seg & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
>>    return (vdev->max_seg >> 8) & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SEG + 2:
>>    return (vdev->max_seg >> 16) & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SEG + 3:
>>    return (vdev->max_seg >> 24) & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SIZE:
>>    return vdev->max_size & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SIZE + 1:
>>    return (vdev->max_size >> 8) & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SIZE + 2:
>>    return (vdev->max_size >> 16) & 0xFF;
>> case VIRTIO_BLK_CONFIG_MAX_SIZE + 3:
>>    return (vdev->max_size >> 24) & 0xFF;
>> ...
>>     
>
> 	struct virtio_blk_config
> 	{
> 		uint32_t max_seg, max_size;
> 	};
>
> 	...
> 	struct virtio_blk_config conf = { vdev->max_seg, vdev->max_size };
>
> 	return ((unsigned char *)&conf)[addr];
>
> (Which strongly implies our headers should expose that nominal struct, rather 
> than numerical constants).
>   

The problem is the ABI.  We can either require that PCI configuration 
values are accessed with natural instructions, or it makes very little 
sense to use the PCI configuration space for virtio configuration 
information.  If we really can't find a way to do this (and I think my 
current implementation is the best compromise since it hides this from 
everything else), then I think I'll switch over to just writing a PFN 
into a PCI configuration slot and then have that page store the virtio 
configuration information (much like is done with lguest).

Either virtio config looks like a shared memory area (as lguest 
currently implements it), or it looks like hardware registers (like 
virtio-pci implements it).  After thinking about it for a while, I don't 
think the two can be reconciled.  There are subtle differences between 
the two that can't be hidden in the virtio interface.  For instance, in 
the PCI model, you get notified when values are read/written whereas in 
the lguest model, you don't and need explicit status bits.

If you're very against the switch() magic, then I'll switch over to just 
using a shared memory area.

Regards,

Anthony Liguori

> Rusty.
>
>   


  reply	other threads:[~2007-11-09 23:45 UTC|newest]

Thread overview: 16+ 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
     [not found] ` <200711070957.44165.rusty__13109.5125260346$1194390035$gmane$org@rustcorp.com.au>
2007-11-06 23:05   ` Anthony Liguori
2007-11-07  6:04     ` [PATCH] " Rusty Russell
2007-11-07 17:30       ` Anthony Liguori
2007-11-08  2:20         ` Rusty Russell
     [not found]         ` <200711081320.35844.rusty__6233.15023626692$1194488552$gmane$org@rustcorp.com.au>
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:47                 ` [Lguest] " ron minnich
2007-11-08 22:49                   ` Anthony Liguori
     [not found]                   ` <4733A6F5.3040202@qumranet.com>
2007-11-09  3:17                     ` Anthony Liguori
2007-11-09 11:54                 ` Rusty Russell
2007-11-09 23:45                   ` Anthony Liguori [this message]
2007-11-10  7:58                     ` Rusty Russell
2007-11-10 22:08                       ` 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=4734F122.8000102@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=dor.laor@qumranet.com \
    --cc=lguest@ozlabs.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox