Michael S. Tsirkin m...@redhat.com writes:
On Wed, May 29, 2013 at 10:47:52AM +0930, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Dec 12, 2011 at 01:49:13PM +0200, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun,
On Mon, Dec 12, 2011 at 01:49:13PM +0200, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Dec 12, 2011 at 01:49:13PM +0200, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM
On Wed, 18 Jan 2012 17:29:49 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Fri, Jan 13, 2012 at 01:32:42PM +1100, Benjamin Herrenschmidt wrote:
Your interrupt may take an unpredictable amount of time to arrive, I
don't see how you can use that as a guarantee.
In theory yes.
On Fri, Jan 13, 2012 at 01:32:42PM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2012-01-13 at 04:19 +0200, Michael S. Tsirkin wrote:
On Thu, Jan 12, 2012 at 12:12:17PM +1030, Rusty Russell wrote:
On Thu, 12 Jan 2012 00:02:33 +0200, Michael S. Tsirkin
m...@redhat.com wrote:
Look, we
On Fri, 13 Jan 2012 04:19:30 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Jan 12, 2012 at 12:12:17PM +1030, Rusty Russell wrote:
On Thu, 12 Jan 2012 00:02:33 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
Look, we have a race currently. Let us not tie a bug fix to a huge
On Thu, Jan 12, 2012 at 12:12:17PM +1030, Rusty Russell wrote:
On Thu, 12 Jan 2012 00:02:33 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
Look, we have a race currently. Let us not tie a bug fix to a huge
rewrite with unclear performance benefits, please.
In theory, yes. In practice,
On Thu, 12 Jan 2012 08:00:10 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Jan 12, 2012 at 12:31:09PM +1030, Rusty Russell wrote:
If we use a 32-bit counter, we also get this though, right?
If counter has changed, it's a config interrupt...
But we need an exit to read the
On Wed, Jan 11, 2012 at 12:25 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and instead perform DMA like a normal PCI device (use bus
addresses).
Euh why ?
That would mean in many cases adding a layer of iommu, which will slow
On Wed, Jan 11, 2012 at 10:55:52AM +1030, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
area is
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
area is flawed. There may be cases
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and instead perform DMA like a normal PCI device (use bus
addresses).
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields
On 01/11/2012 09:12 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:12 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkinm...@redhat.com
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
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring
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
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.
On Wed, Jan 11, 2012 at 10:02:51AM -0600, Anthony Liguori wrote:
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:
On Wed, Jan 11, 2012 at 3:39 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 05:21:53PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 3:39 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 11, 2012 at 02:28:48PM +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
Regards,
Anthony Liguori
___
On Wed, Jan 11, 2012 at 01:42:39PM -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
Sure.
See
On Wed, 2012-01-11 at 14:28 +, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 9:10 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-01-11 at 08:47 +, Stefan Hajnoczi wrote:
This is also an opportunity to stop using CPU physical addresses in
the ring and
On Wed, 2012-01-11 at 17:12 +0200, Michael S. Tsirkin 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.
Do like real HW, there's plenty of options:
- (better) Have a command update MAC
On Wed, 2012-01-11 at 17:21 +0200, Michael S. Tsirkin wrote:
Possible but doesn't let us layer nicely to allow unchanged drivers
that work with all transports (new pci, old pci, non pci).
Something like a command VQ would be a generic transport
that can be hidden behind config-set(...).
I
On Wed, 2012-01-11 at 13:42 -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
I wouldn't be
On Wed, 2012-01-11 at 14:26 -0600, Anthony Liguori wrote:
I'd say that's a special case but I see what you're getting at here.
So what about keeping the config space read-only and using control
queues for
everything else?
Which is exactly what Rusty and I are proposing :-) I would go
On Wed, Jan 11, 2012 at 02:26:55PM -0600, Anthony Liguori wrote:
On 01/11/2012 02:14 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 01:42:39PM -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common
On Thu, Jan 12, 2012 at 08:02:06AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2012-01-11 at 14:26 -0600, Anthony Liguori wrote:
I'd say that's a special case but I see what you're getting at here.
So what about keeping the config space read-only and using control
queues for
On Thu, 2012-01-12 at 00:02 +0200, Michael S. Tsirkin wrote:
We could probably have a helper library for sending control messages
which could handle waiting for a ring slot to be free (practically
always the case on control queues), writing the message, sending it
and
waiting for a status
On Thu, 2012-01-12 at 00:13 +0200, Michael S. Tsirkin wrote:
We typically pre-populate the data rings with skb's for 1500 and 9000
bytes packets. Small packets come in immediately in the completion ring,
and large packets via the data ring.
Won't real workloads suffer from packet
On Thu, 2012-01-12 at 00:13 +0200, Michael S. Tsirkin wrote:
Well, I would argue that the network driver world has proven countless
times that those are good ideas :-)
Below you seem to suggest that separate rings like
virtio has now is better than a single ring like Rusty
suggested.
I
On Thu, 12 Jan 2012 00:02:33 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
Look, we have a race currently. Let us not tie a bug fix to a huge
rewrite with unclear performance benefits, please.
In theory, yes. In practice, we bandaid it.
I think in the short term we change -get to get the
On Wed, 11 Jan 2012 07:30:34 -0600, Anthony Liguori anth...@codemonkey.ws
wrote:
I think the more important thing to do is require accesses to integers in the
config space to always be aligned and to use the appropriate accessor.
Non-integer fields should be restricted to byte access.
On Thu, 2012-01-12 at 12:31 +1030, Rusty Russell wrote:
Are we going to keep guest endian for e.g. virtio net header?
If yes the benefit of switching config space is not that big.
And changes in devices would affect non-PCI transports.
Yep. It would only make sense if we do it for
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
On Tue, 20 Dec 2011 13:37:18 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Dec 19, 2011 at 09:38:42PM +1030, Rusty Russell wrote:
On Mon, 19 Dec 2011 11:13:26 +0200, Michael S. Tsirkin
m...@redhat.com wrote:
On Wed, 2012-01-11 at 10:55 +1030, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
Yes. The idea that we can alter fields in the device-specific config
area is flawed.
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
What does the host do
if the guest screws things up? How long do you wait for them to
complete the seqlock? Or does it save the old version for use in the
duration?
Yes, it will have to only apply the change when
On Mon, Dec 19, 2011 at 09:38:42PM +1030, Rusty Russell wrote:
On Mon, 19 Dec 2011 11:13:26 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Dec 19, 2011 at 04:36:38PM +1030, Rusty Russell wrote:
On Sun, 18 Dec 2011 12:18:32 +0200, Michael S. Tsirkin
m...@redhat.com wrote:
On Mon, Dec 19, 2011 at 04:36:38PM +1030, Rusty Russell wrote:
On Sun, 18 Dec 2011 12:18:32 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
appears and
On Mon, 19 Dec 2011 11:13:26 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Dec 19, 2011 at 04:36:38PM +1030, Rusty Russell wrote:
On Sun, 18 Dec 2011 12:18:32 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
On Thu, 15 Dec 2011 10:27:50 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
I mean like this in block:
/* Host must always specify the capacity.
On Sun, 18 Dec 2011 12:18:32 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
appears and vanishes around config writes by either side? Kind of a
hack
On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
On Mon, 12 Dec 2011 20:25:34 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
By the way, a generic question on virtio-pci: we now have:
/* virtio config-get() implementation */
static void vp_get(struct virtio_device
On Thu, 15 Dec 2011 10:27:50 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
I mean like this in block:
/* Host must always specify the capacity. */
vdev-config-get(vdev, offsetof(struct virtio_blk_config,
On Mon, 12 Dec 2011 13:10:08 -0500, Don Dutile ddut...@redhat.com wrote:
On 12/12/2011 06:49 AM, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Thu, Dec 08, 2011 at
On Mon, 12 Dec 2011 20:25:34 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
By the way, a generic question on virtio-pci: we now have:
/* virtio config-get() implementation */
static void vp_get(struct virtio_device *vdev, unsigned offset,
void *buf, unsigned len)
{
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is no iowrite64. We use two 32-bit ops. */
+static void iowrite64(u64
On 12/12/2011 06:49 AM, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkinm...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is no iowrite64. We use two
On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is no iowrite64. We use two 32-bit ops. */
+static void iowrite64(u64
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is no iowrite64. We use two 32-bit ops. */
+static void iowrite64(u64 val, const __le64 *addr)
+{
+ iowrite32((u32)val, (__le32 *)addr);
+ iowrite32(val 32, (__le32 *)addr + 1);
+}
+
Let's put
On Sun, 11 Dec 2011 11:42:56 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
+/* There is no iowrite64. We use two 32-bit ops. */
+static void iowrite64(u64 val, const __le64 *addr)
+{
+ iowrite32((u32)val, (__le32
Differences:
1) Uses 4 pci capabilities to demark common, irq, notify and dev-specific areas.
2) Guest sets queue size, using host-provided maximum.
3) Guest sets queue alignment, rather than ABI-defined 4096.
4) More than 32 feature bits (a lot more!).
---
drivers/virtio/Makefile |1
56 matches
Mail list logo
