"Michael S. Tsirkin" writes:
> On Mon, Mar 16, 2015 at 01:44:22PM +1030, Rusty Russell wrote:
>> diff --git a/content.tex b/content.tex
>> index 6ba079d..2c946a5 100644
>> --- a/content.tex
>> +++ b/content.tex
>> @@ -600,10 +600,19 @@ them: it is
"Michael S. Tsirkin" writes:
> On Mon, Mar 09, 2015 at 05:43:19PM +1030, Rusty Russell wrote:
>> > I think it's a good idea to merge these patches (maybe except the
>> > !TASK_RUNNING thing) sooner rather than later, to make sure people have
>> > th
"Michael S. Tsirkin" writes:
> On Fri, Mar 13, 2015 at 11:47:18AM +1030, Rusty Russell wrote:
>> Here's my proposed spec patch, which spells this out:
>>
>> diff --git a/content.tex b/content.tex
>> index 6ba079d..b6345a8 100644
>> --- a/conten
"Michael S. Tsirkin" writes:
> On Wed, Mar 11, 2015 at 02:19:03PM +0100, Michael S. Tsirkin wrote:
>> QEMU wants to use virtio scsi structures with
>> a different VIRTIO_SCSI_CDB_SIZE/VIRTIO_SCSI_SENSE_SIZE,
>> let's add ifdefs to allow overriding them.
>>
>> Keep the old defines under new names:
"Michael S. Tsirkin" writes:
> On Thu, Mar 12, 2015 at 11:34:35AM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > On Wed, Mar 11, 2015 at 10:06:40PM +1030, Rusty Russell wrote:
>> >> Each entry in the ring is a pair: \f
"Michael S. Tsirkin" writes:
> On Wed, Mar 11, 2015 at 10:06:40PM +1030, Rusty Russell wrote:
>> Each entry in the ring is a pair: \field{id} indicates the head
>> entry of the descriptor chain describing the buffer (this
>> matches an entry
Ohad Ben-Cohen writes:
> On Mon, Mar 9, 2015 at 10:41 AM, Michael S. Tsirkin wrote:
>> On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote:
>>> virtio spec requires that all drivers set DRIVER_OK
>>> before using devices. While rpmsg isn't yet
>>> included in the virtio 1 spec, pre
"Michael S. Tsirkin" writes:
> On Wed, Mar 11, 2015 at 04:29:32PM +1030, Rusty Russell wrote:
>> We only fill in the 'req->qiov.size' bytes on a (successful) read,
>> not on a write.
>>
>> Signed-off-by: Rusty Russell
>> ---
>>
"Michael S. Tsirkin" writes:
> On Wed, Mar 11, 2015 at 02:47:47PM +0800, Fam Zheng wrote:
>> On Wed, 03/11 07:19, Michael S. Tsirkin wrote:
>> > On Wed, Mar 11, 2015 at 04:29:30PM +1030, Rusty Russell wrote:
>> > > The virtio 'used' ring describes
We only fill in the 'req->qiov.size' bytes on a (successful) read,
not on a write.
Signed-off-by: Rusty Russell
---
hw/block/virtio-blk.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 258bb4c..9
behaviour.
The first patch changes the 'len' formal parameter name to 'len_written' to
make the API clearer, and adds an assert(). The second fixes block writes.
Cheers,
Rusty.
PS. It's based on MST's virtio-1.0 tree, but should be easily ported.
Rusty Russell (2):
And enforce this with a check that it's <= the writable length.
Signed-off-by: Rusty Russell
---
hw/virtio/virtio.c | 19 ---
include/hw/virtio/virtio.h | 4 ++--
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/
"Michael S. Tsirkin" writes:
> Hi Rusty!
> There are a bunch of (mostly virtio 1.0 related) fixes for virtio
> that need to go into 4.0 I think.
> virtio_blk: typo fix
> virtio_blk: fix comment for virtio 1.0
OK, I've added these two. I tend to be overcautious after the merge
window.
"Michael S. Tsirkin" writes:
> virtio spec requires that all drivers set DRIVER_OK
> before using devices. While rpmsg isn't yet
> included in the virtio 1 spec, previous spec versions
> also required this.
>
> virtio rpmsg violates this rule: is calls kick
> before setting DRIVER_OK.
>
> The fix
"Michael S. Tsirkin" writes:
> On Wed, Mar 04, 2015 at 11:06:08AM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > virtio 1.0 config space is in LE format for all
>> > devices, use modern wrappers when accessed through
>> &
"Michael S. Tsirkin" writes:
> virtio 1.0 config space is in LE format for all
> devices, use modern wrappers when accessed through
> the 1.0 BAR.
Hmm, I'm not so sure about these patches. It's easy to miss the
existence of the _modern variants, and they're 90% the same as the
legacy variants.
"Michael S. Tsirkin" writes:
> Fix up comment to match virtio 1.0 logic:
> virtio_blk_outhdr isn't the first elements anymore,
> the only requirement is that it comes first in
> the s/g list.
>
> Signed-off-by: Michael S. Tsirkin
Thanks, both applied.
Cheers,
Rusty.
on my x86 laptop, and a BE and LE guest
on a BE powerpc machine, to check that all combinations work correctly.
If others test too, that would be appreciated!
Cheers,
Rusty.
>From 95ac91554ed602f856a2a5fcc25eaffcad1b1c8d Mon Sep 17 00:00:00 2001
From: Rusty Russell
Date: Tue, 24 Feb 2015 1
Cornelia Huck writes:
> Note that we care only about the fields still in use for virtio v1.0.
>
> Reviewed-by: Thomas Huth
> Reviewed-by: David Hildenbrand
> Signed-off-by: Cornelia Huck
Hi Cornelia,
These patches all look good; I'm a bit nervous about our testing
missing some convers
Cornelia Huck writes:
> With virtio-1, we support more than 32 feature bits. Let's make
> vdev->guest_features depend on the number of supported feature bits,
> allowing us to grow the feature bits automatically.
It's a judgement call, but I would say that simply using uint64_t
will be sufficient
Jan Kiszka writes:
> On 2014-06-12 04:27, Rusty Russell wrote:
>> Henning Schild writes:
>> It was also never implemented, and remains a thought experiment.
>> However, implementing it in lguest should be fairly easy.
>
> The reason why a trusted helper, i.e. additiona
Henning Schild writes:
> Hi,
>
> i am working on the jailhouse[1] project and am currently looking at
> inter-VM communication. We want to connect guests directly with virtual
> consoles based on shared memory. The code complexity in the hypervisor
> should be minimal, it should just make the shar
Alexander Graf writes:
> On 05/07/2014 12:19 PM, Greg Kurz wrote:
> The uglyness about the current_cpu bit is that devices are usually not
> supposed to know about the cpu accesses come from usually. But then
> again devices shouldn't know about the endianness of a cpu either so I
> guess it's
Amos Kong writes:
> Current hwrng core supports to register multiple hwrng devices,
> and there is only one device really works in the same time.
> QEMU alsu supports to have multiple virtio-rng backends.
>
> This patch changes virtio-rng driver to support multiple
> virtio-rng devices.
I never t
Markus Armbruster writes:
> Rusty Russell writes:
>> The litmus test: does *your* guest handle failures other than by giving
>> up on the device? If so, sure, you need to have a sane error-reporting
>> strategy.
>
> Err, isn't this a circular argument? No need
Dave Airlie writes:
> So I'm looking at how best to do virtio gpu device error reporting,
> and how to deal with illegal stuff,
>
> I've two levels of errors I want to support,
>
> a) unrecoverable or bad guest kernel programming errors,
The QEMU standard approach is to exit at this point. No, r
Alexander Graf writes:
> On 02/18/2014 05:17 PM, Cornelia Huck wrote:
>> Hm. So whatever_le for 1.0 devices, and virtio_whatever (checking the
>> byteswap value) for legacy devices? The device implementation will be
>> aware of the virtio version anyway.
>
> Yeah, but I would hope we want to share
..2e22a47
>> > --- /dev/null
>> > +++ b/include/hw/virtio/virtio-access.h
>> > @@ -0,0 +1,132 @@
>> > +/*
>> > + * Virtio Accessor Support: In case your target can change endian.
>> > + *
>> > + * Copyright IBM, Corp. 2013
>> >
Thomas Huth writes:
> On Thu, 17 Oct 2013 14:23:35 +1030
> Rusty Russell wrote:
>
>> This is a re-transmit of the core of the virtio endian code. Since
>> there seems to be some interest in ARM BE virtio, I've separated this from
>> the direct problem I was so
Laszlo Ersek writes:
> Hi,
>
> "Appendix X: virtio-mmio" in the virtio spec says
Hi Laszlo,
You're in luck! We're currently revising the virtio spec under
the OASIS banner. I'd really like you to post your suggestion to their
mailing list (yes, you will have
to subscribe to it, for IP
This is a re-transmit of the core of the virtio endian code. Since
there seems to be some interest in ARM BE virtio, I've separated this from
the direct problem I was solving: PowerPC LE.
Please apply!
Rusty.
Rusty Russell (7):
virtio_get_byteswap: function for endian-ambivalent targets
Signed-off-by: Rusty Russell
Reviewed-by: Anthony Liguori
---
hw/net/virtio-net.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 22dbd05..431a4b6 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
Signed-off-by: Rusty Russell
Reviewed-by: Anthony Liguori
---
hw/scsi/virtio-scsi.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi
Signed-off-by: Rusty Russell
Reviewed-by: Anthony Liguori
---
hw/virtio/virtio-balloon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 9504877..97c4ac5 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio
This is based on a simpler patch by Anthony Liguouri, which only handled
the vring accesses. We also need some drivers to access these helpers,
eg. for data which contains headers.
Signed-off-by: Rusty Russell
---
hw/virtio/virtio.c | 28 ++--
1 file changed, 14
Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
Signed-off-by: Rusty Russell
Reviewed-by: Anthony Liguori
---
hw/block/virtio-blk.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw
at device
reset time (which is done before any driver is loaded) since it
may involve a system call to get the status when running under kvm.
Signed-off-by: Rusty Russell
---
hw/virtio/virtio.c| 6 ++
include/hw/virtio/virtio-access.h | 133 +
Signed-off-by: Rusty Russell
Reviewed-by: Anthony Liguori
---
hw/char/virtio-serial-bus.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 703f026..2dc0ccf 100644
--- a/hw
Greg Kurz writes:
> We need to support the guest endianness as soon as a virtio device shows
> up. Alex suggested this can achieved by calling cpu_synchronize_state().
>
> To have it working on PowerPC, we need to add LPCR in the sync register
> functions.
>
> Signed-off-by: Greg Kurz
Excellent!
Greg Kurz writes:
> Follow-up to Rusty's virtio endianness serie: enough to get a working
> virtfs mount.
>
> Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
>
> Signed-off-by: Greg Kurz
Thanks!
I've reworked my patches in line with the anticipated KVM_GET_ONE_REG
fro
Benjamin Herrenschmidt writes:
> On Mon, 2013-08-12 at 17:29 +0930, Rusty Russell wrote:
>> virtio data structures are defined as "target endian", which assumes
>> that's a fixed value. In fact, that actually means it's
>> platform-specific.
>>
"Xie, Huawei" writes:
> If this is the case, one possible fix would be:
> Write two continuous 32bit DWORD to combine a 64bit address
> Use the upper 12 bits of PFN val to indicate if it is combined write
> In this way, we wouldn't break other virtio driver, register layout
> and only
Benjamin Herrenschmidt writes:
> On Tue, 2013-08-13 at 13:50 +0930, Rusty Russell wrote:
>> We can have it call once (eg. when the first and storing the status
>> word) and store the result.
>
> And fail with kexec of a different endian kernel :-) Let's not bother
>
Anthony Liguori writes:
> Benjamin Herrenschmidt writes:
>
>> On Mon, 2013-08-12 at 17:29 +0930, Rusty Russell wrote:
>>> virtio data structures are defined as "target endian", which assumes
>>> that's a fixed value. In fact, that actually means i
We base it on the OS endian, as reflected by the endianness of the
interrupt vectors.
Suggested-by: Benjamin Herrenschmidt
Signed-off-by: Rusty Russell
---
target-ppc/misc_helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target-ppc/misc_helper.c b/target-ppc/misc_helper.c
virtio data structures are defined as "target endian", which assumes
that's a fixed value. In fact, that actually means it's
platform-specific.
Hopefully the OASIS virtio 1.0 spec will fix this. Meanwhile, create
a hook for little endian ppc.
Signed-off-by: Rusty Russ
The driver parts (patches 3-8) are unchanged, so didn't repost.
1) Rebased onto more recent git tree.
2) New stub is virtio_get_byteswap()
3) PPC64 uses endianness of first CPU interrupt vectors, not CPU endiannes.
Hope this one is closer...
Rusty.
Rusty Russell (8):
virtio_get_byt
Peter Maydell writes:
> On 9 August 2013 08:35, Rusty Russell wrote:
>> That's a lot of replumbing and indirect function calls for a fairly
>> obscure case. We certainly don't have a nice CPUState lying around in
>> virtio at the moment, for example.
>
> Ac
This is based on a simpler patch by Anthony Liguouri, which only handled
the vring accesses. We also need some drivers to access these helpers,
eg. for data which contains headers.
Signed-off-by: Rusty Russell
---
hw/virtio/virtio.c | 29 +++--
1 file changed, 15
Benjamin Herrenschmidt writes:
> This whole exercise should have nothing to do with the current endian
> mode of the CPU. If for example you are running lx86 (the x86 emulator
> IBM provides) which exploits MSR:LE on POWER7 to run x86 binaries in
> userspace, you don't want virtio to suddenly chan
Anthony Liguori writes:
> Rusty Russell writes:
>> (Qemu run under eatmydata to eliminate syncs)
>
> FYI, cache=unsafe is equivalent to using eatmydata.
Ah, thanks!
> I can reproduce this although I also see a larger standard deviation.
>
> BEFORE:
>
Andreas Färber writes:
> Am 08.08.2013 17:40, schrieb Anthony Liguori:
>> Andreas Färber writes:
>>> Am 08.08.2013 15:31, schrieb Anthony Liguori:
We have a mechanism to do weak functions via stubs/. I think it would
be better to do cpu_get_byteswap() as a stub function and then overlo
Andreas Färber writes:
> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>> Rusty Russell writes:
>> We have a mechanism to do weak functions via stubs/. I think it would
>> be better to do cpu_get_byteswap() as a stub function and then overload
>> it in the ppc64 cod
Anthony Liguori writes:
> I suspect this is a premature optimization. With a weak function called
> directly in the accessors below, I suspect you would see no measurable
> performance overhead compared to this approach.
>
> It's all very predictable so the CPU should do a decent job optimizing
>
Anthony Liguori writes:
> "Daniel P. Berrange" writes:
>
>> On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote:
>>> Andreas Färber writes:
>>> >> We have a mechanism to do weak functions via stubs/. I think it would
>>> >> be better to do cpu_get_byteswap() as a stub function and t
Andreas Färber writes:
> Am 08.08.2013 15:31, schrieb Anthony Liguori:
>> Rusty Russell writes:
>>
>>> Virtio is currently defined to work as "guest endian", but this is a
>>> problem if the guest can change endian. As most targets can't chan
Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
Signed-off-by: Rusty Russell
---
hw/block/virtio-blk.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index cf12469
g accesses. We also need some drivers to access these helpers,
eg. for data which contains headers.
Signed-off-by: Rusty Russell
---
hw/virtio/virtio.c| 46 +
include/hw/virtio/virtio-access.h | 138 ++
2 files changed, 170 in
---
hw/char/virtio-serial-bus.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index cc3d1dd..0421725 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -2
Signed-off-by: Rusty Russell
---
hw/virtio/virtio-balloon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index d669756..c0b4f6e 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -30,6 +30,7
Signed-off-by: Rusty Russell
---
configure| 1 +
target-ppc/misc_helper.c | 8
2 files changed, 9 insertions(+)
diff --git a/configure b/configure
index ad32f87..cee32af 100755
--- a/configure
+++ b/configure
@@ -4217,6 +4217,7 @@ case "$target_name" i
Note that st*_raw and ld*_raw are effectively replaced by st*_p and ld*_p.
Signed-off-by: Rusty Russell
---
hw/scsi/virtio-scsi.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 08dd3f3
Virtio is currently defined as "guest-endian", but that's a slippery
concept when the target can change endian. In particular, virtio devices
fail on little-endian powerpc 64.
Feedback welcome!
Rusty.
Rusty Russell (7):
virtio: allow byte swapping for vring and config acce
Signed-off-by: Rusty Russell
---
hw/char/virtio-serial-bus.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index cc3d1dd..0421725 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw
Signed-off-by: Rusty Russell
---
hw/net/virtio-net.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 1ea9556..e77e28d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -21,6 +21,7 @@
#include &qu
Anthony Liguori writes:
> "Michael S. Tsirkin" writes:
>
>> On Thu, Jul 25, 2013 at 04:56:05PM +0200, Andreas Färber wrote:
>>> Am 25.07.2013 16:52, schrieb Michael S. Tsirkin:
>>> > On Thu, Jul 25, 2013 at 08:28:00AM -0500, Anthony Liguori wrote:
>>> >> We have a pretty awful legacy command line
Anthony Liguori writes:
> On Wed, Jul 24, 2013 at 8:55 PM, Rusty Russell wrote:
>> Hi all,
>>
>> Using latest kernel and master qemu, the following doesn't use
>> vhost acceleration:
>>
>> sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m
Hi all,
Using latest kernel and master qemu, the following doesn't use
vhost acceleration:
sudo qemu-system-x86_64 -machine pc,accel=kvm $ARGS -m 1024 -net
tap,script=/home/rusty/bin/kvm-ifup,downscript=no,vhost=on -net
nic,model=virtio -drive file=$QEMUIMAGE,index=0,media=disk,if=virti
"Michael S. Tsirkin" writes:
> On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > For small packets we can simplify xmit processing
>> > by linearizing buffers with the header:
>> > most p
Dave Airlie writes:
> Hi Rusty,
>
> playing with my virtio gpu, I started hitting the qemu
> error_report("Too many read descriptors in indirect table");
>
> Now I'm not sure but this doesn't seem to be a virtio limit that the
> guest catches from what I can see, since my host dies quite quickly,
"Michael S. Tsirkin" writes:
> For small packets we can simplify xmit processing by linearizing buffers
> with the header: most packets seem to have enough head room we can use
> for this purpose.
>
> Since some older hypervisors (e.g. qemu before version 1.5)
> required that header is the first s
"Michael S. Tsirkin" writes:
> Some setups don't support enabling BAR0 (IO BAR). Reasons range from CPU
> limitations (e.g. on some powerpc setups) to architecture limmitations
> (e.g. a setup with >15 PCI bridges, with one virtio device behind each,
> on x86).
>
> PCI Express spec made IO optiona
Anthony Liguori writes:
> "Michael S. Tsirkin" writes:
>
>> On Thu, May 30, 2013 at 08:40:47AM -0500, Anthony Liguori wrote:
>>> Stefan Hajnoczi writes:
>>>
>>> > On Thu, May 30, 2013 at 7:23 AM, Rusty Russell
>>> > wrot
Stefan Hajnoczi writes:
> On Thu, May 30, 2013 at 7:23 AM, Rusty Russell wrote:
>> On the receive side, what can we do better than readv? If we need to
>> return to userspace to tell the guest that we've got a new packet, we
>> don't win on latency. We might
Anthony Liguori writes:
> Rusty Russell writes:
>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>>> FWIW, I think what's more interesting is using vhost-net as a networking
>>> backend with virtio-net in QEMU being what's guest facing.
&
Anthony Liguori writes:
> The headers say they are BSD licensed... but they include a GPLv2+
> header. Doesn't make a lot of sense, does it?
It makes perfect sense: you're overthinking it. It just means that
copying the BSD headers outside Linux is encouraged.
And it's clearly nonsensical to c
Anthony Liguori writes:
> Rusty Russell writes:
>
>> Anthony Liguori writes:
>>> Paolo Bonzini writes:
>>>
>>>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>>>> > My fault. I should have looked at linux/types.h (actually
&g
"Michael S. Tsirkin" writes:
> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Fri, May 24, 2013 at 05:41:11PM +0800, Jason Wang wrote:
>> >> On 05/23/2013 04:50 PM, Michael S. Tsirkin wrote:
>> >> > Hey guys,
>> >> > I've updated the k
Anthony Liguori writes:
> Paolo Bonzini writes:
>
>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>> > My fault. I should have looked at linux/types.h (actually asm-generic/).
>>>
>>> Not really, __uX appear in the headers that were posted.
>
> Which is a problem because this is a reser
"Michael S. Tsirkin" writes:
> On Mon, May 20, 2013 at 03:43:51PM +0200, Paolo Bonzini wrote:
>> Is there a story behind skipping virtio-net feature bits 2..4?
>>
>> Paolo
>
> Bits 3-4 now :)
> I'm curious too.
Not a good one :)
The year is 2007. virtio_net was the posterchild of free expressi
Dmitry Fleytman writes:
> Spec patch already inside.
>
> Sent from my iPad
>
> On Apr 20, 2013, at 8:04 PM, "Michael S. Tsirkin" wrote:
>
>> On Fri, Apr 19, 2013 at 10:10:01AM +0300, Dmitry Fleytman wrote:
>>> Hello All,
>>>
>>> Any news regarding this patch?
>>>
>>> Thanks,
>>> Dmitry
>>
>> R
Dmitry Fleytman writes:
> From: Dmitry Fleytman
>
> Virtio-net driver currently negotiates network offloads
> on startup via features mechanism and have no ability to
> change offloads state later.
> This patch introduced a new control command that allows
> to configure device network offloads st
"Michael S. Tsirkin" writes:
> On Thu, Mar 21, 2013 at 02:44:50PM +0800, Amos Kong wrote:
>> The lengcy guests don't have mac programming command, we don't know when
>> it's safe to use MAC. This patch changed qemu to makes MAC change effect
>> when the last byte of MAC is written to config space.
Cornelia Huck writes:
> On Thu, 7 Mar 2013 20:02:21 +0200
> "Michael S. Tsirkin" wrote:
>
>> virtio-s390 on kvm can use a cookie value passed to guest
>
> s/virtio-s390/virtio-ccw/ (to avoid confusion with s390-virtio, which
> was never specced)
>
>> to optimize channel/VQ lookups.
>> Document th
"Michael S. Tsirkin" writes:
> Maybe we should ask for some centrally assigned vendor id?
> We could ask IANA to keep the database.
Or we could make it the task of the virtio spec. I don't think it's
vital...
Cheers,
Rusty.
Vadim Rozenfeld writes:
> On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
>> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
>> Is it really
>> > that bad that the config space size changed? Why it has this effect?
> Because in this case it's hard to distinguish bet
Anthony Liguori writes:
> Rusty Russell writes:
>> If I could find a way, I'd like to create some code as an appendix to
>> the virtio spec which would torture test each driver and/or device by
>> configuring it in strange ways. But that's pure speculation at th
Anthony Liguori writes:
> Michael Tokarev writes:
>
>> 03.02.2013 17:23, Yan Vugenfirer wrote:
>>
If it helps, mq changes the config size from 8 to 16 bytes. If the
driver was making an assumption about an 8-byte config size, that's
likely what the problem is.
>>> That's exac
ak...@redhat.com writes:
> @@ -349,6 +351,14 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
> cmd,
> {
> struct virtio_net_ctrl_mac mac_data;
>
> +if (cmd == VIRTIO_NET_CTRL_MAC_ADDR_SET && elem->out_num == 2 &&
> +elem->out_sg[1].iov_len == ETH_ALEN) {
> +/*
"Michael S. Tsirkin" writes:
>> +if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
>> +/* Set MAC address by writing config space */
>> vdev->config->set(vdev, offsetof(struct virtio_net_config, mac),
>>dev->dev_addr, dev->addr_len);
>>
"Michael S. Tsirkin" writes:
> On Thu, Jan 10, 2013 at 10:45:39PM +0800, ak...@redhat.com wrote:
>> From: Amos Kong
>>
>> Currenly mac is programmed byte by byte. This means that we
>> have an intermediate step where mac is wrong.
>>
>> Second patch introduced a new vq control command to set
"Michael S. Tsirkin" writes:
> On Tue, Dec 18, 2012 at 03:57:17PM +0100, Stefan Hajnoczi wrote:
>> > > @@ -407,6 +409,14 @@ static void virtio_blk_handle_output(VirtIODevice
>> > > *vdev, VirtQueue *vq)
>> > > .num_writes = 0,
>> > > };
>> > >
>> > > +/* Some guests kick befor
Anthony Liguori writes:
> Yes, take a look at the series I sent out that scrubs all of this to
> just send the index and the addresses of the element.
>
> We technically should save the addresses and sizes too. It makes it a
> heck of a lot safer then re-reading guest memory since we do some
> va
Anthony Liguori writes:
> Rusty Russell writes:
>
>> Anthony Liguori writes:
>>> We were memcpy()'ing a structure to the wire :-/ Since savevm really
>>> only works on x86 today, lets just declare that this element is sent
>>> over the wire as a lit
Anthony Liguori writes:
> We were memcpy()'ing a structure to the wire :-/ Since savevm really
> only works on x86 today, lets just declare that this element is sent
> over the wire as a little endian value in order to fix the bitness.
>
> Unfortunately, we also send raw pointers and size_t which
Anthony Liguori writes:
> Rusty Russell writes:
>
>> "Michael S. Tsirkin" writes:
>>
>> No, because I don't understand it. Is it true for the case of
>> virtio_blk, which has outstanding requests?
>>
>>>> Currently we
"Michael S. Tsirkin" writes:
> On Thu, Dec 06, 2012 at 04:33:06PM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > Add sanity check to address the following concern:
>> >
>> > On Wed, Dec 05, 2012 at 09:47:22AM +1030, Ru
"Michael S. Tsirkin" writes:
> Add sanity check to address the following concern:
>
> On Wed, Dec 05, 2012 at 09:47:22AM +1030, Rusty Russell wrote:
>> All we need is the index of the request; the rest can be re-read from
>> the ring.
The terminology I used here
Juan Quintela writes:
> Rusty Russell wrote:
>> Hi all,
>>
>> I want to rework the qemu virtio subsystem, but various
>> structures are currently blatted to disk in save/load. So I looked at
>> altering that, only to discover that it needs conversion t
Hi all,
I want to rework the qemu virtio subsystem, but various
structures are currently blatted to disk in save/load. So I looked at
altering that, only to discover that it needs conversion to vmstate, and
2009 patches in patchwork which have never been applied.
Has there been any progr
1 - 100 of 211 matches
Mail list logo
