From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver. Date: Wed, 11 Jan 2012 10:02:51 -0600 Message-ID: <4F0DB2AB.8030506@codemonkey.ws> References: <871us0om2t.fsf@rustcorp.com.au> <20111220113718.GF3913@redhat.com> <878vm6daqy.fsf@rustcorp.com.au> <20120110170334.GA18404@redhat.com> <8762gj6q5r.fsf@rustcorp.com.au> <4F0D8EFA.3010503@codemonkey.ws> <20120111151230.GA20570@redhat.com> <4F0DA7A5.7050600@codemonkey.ws> <20120111152129.GB20570@redhat.com> <4F0DAA9B.7060703@codemonkey.ws> <20120111154515.GD20570@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120111154515.GD20570@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "Michael S. Tsirkin" Cc: Pawel Moll , Benjamin Herrenschmidt , virtualization , Christian Borntraeger , Sasha Levin List-Id: virtualization@lists.linuxfoundation.org On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote: > On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote: >> On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote: >>> On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote: >>>>> This is similar to what we have now. But it's still buggy: e.g. if guest >>>>> updates MAC byte by byte, we have no way to know when it's done doing >>>>> so. >>>> >>>> This is no different than a normal network card. You have to use a >>>> secondary register to trigger an update. >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>> >>> Possible but doesn't let us layer nicely to allow unchanged drivers >>> that work with all transports (new pci, old pci, non pci). >> >> If we declare config space LE, then we have to touch all drivers. >> There's no way around it because the virtio API is byte-based, not >> word based. > > Fine but don't we want to be compatible with old hypervisors? We can modify the drivers to work either with a virtio1 or virtio2 transport. If the only difference is that we move to word access instead of byte access for the config space, it's a nop because drivers don't rely on sub-word access today. >> This is why I'm suggesting making the virtio API (and then the >> virtio-pci ABI) word based. It gives us the flexibility to make >> endianness a property of the transport and not a property of the >> devices. >> >> Regards, >> >> Anthony Liguori > > Some fields are 64 bit, this is still tricky to do atomically. > What's the objection to using a config VQ? Then we move very far away from something that looks like a PCI device. The problem we're having here is specifically where we've deviated from what a normal PCI device would do. Fixing that by deviating even further seems counter intuitive to me. Regards, Anthony Liguori >