* Sasha Levin levinsasha...@gmail.com wrote:
+#define PCI_VENDOR_ID_REDHAT_QUMRANET0x1af4
+#define PCI_DEVICE_ID_VIRTIO_RNG 0x1004
+#define PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET 0x1af4
+#define PCI_SUBSYSTEM_ID_VIRTIO_RNG
* Asias He asias.he...@gmail.com wrote:
With commit d7f0c07afeefa2d20739437306e4b8bb2853cf83 in master
(kvm tools: Fix virt_queue__set_used_elem)
I see this:
asias@hj:~/qemu-stuff/pekka.git/tools/kvm$ make
GEN include/common-cmds.h
../../include/asm-generic/bitops/fls64.h:33:2:
On Thu, May 5, 2011 at 9:54 AM, Ingo Molnar mi...@elte.hu wrote:
The code looks correct but we really need to try harder to keep the tools/kvm/
code maintainable!
Aww, I must have been on crack when I applied that. Sasha, please send
a follow up patch to address Ingo's comments.
* Pekka Enberg penb...@kernel.org wrote:
On Thu, May 5, 2011 at 9:54 AM, Ingo Molnar mi...@elte.hu wrote:
The code looks correct but we really need to try harder to keep the
tools/kvm/
code maintainable!
Aww, I must have been on crack when I applied that. Sasha, please send
a follow
On Thu, May 5, 2011 at 10:02 AM, Ingo Molnar mi...@elte.hu wrote:
* Asias He asias.he...@gmail.com wrote:
With commit d7f0c07afeefa2d20739437306e4b8bb2853cf83 in master
(kvm tools: Fix virt_queue__set_used_elem)
I see this:
asias@hj:~/qemu-stuff/pekka.git/tools/kvm$ make
GEN
On Thu, May 5, 2011 at 10:12 AM, Ingo Molnar mi...@elte.hu wrote:
another thing i noticed: the patch introduces some new uint_* usages.
Once things are fixed can we somehow kill that datatype intelligently, so that
if new code uses it the build breaks or so?
I guess we could do
btw., another, wider code structure thought: with the recent (very nice!)
amassing of new virtio drivers, isnt it time to put them into their own
directory in tools/kvm/virtio/?
That way there would be:
tools/kvm/virtio/core.c
tools/kvm/virtio/net.c
tools/kvm/virtio/blk.c
On Thu, 2011-05-05 at 10:13 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:02 AM, Ingo Molnar mi...@elte.hu wrote:
* Asias He asias.he...@gmail.com wrote:
With commit d7f0c07afeefa2d20739437306e4b8bb2853cf83 in master
(kvm tools: Fix virt_queue__set_used_elem)
I see this:
On Thu, 2011-05-05 at 10:14 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:12 AM, Ingo Molnar mi...@elte.hu wrote:
another thing i noticed: the patch introduces some new uint_* usages.
Once things are fixed can we somehow kill that datatype intelligently, so
that
if new code uses
On Thu, May 5, 2011 at 10:18 AM, Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-05-05 at 10:13 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:02 AM, Ingo Molnar mi...@elte.hu wrote:
* Asias He asias.he...@gmail.com wrote:
With commit
Hi,
the subject's tag (qemu-kvm) is misleading. This is actually targeting
the uq/master patch queue, i.e. the upstream kvm staging area.
On 2011-05-05 05:03, brill...@viatech.com.cn wrote:
When KVM is running on VIA CPU with host cpu's model, the feautures of
VIA CPU will be passed into kvm
* Pekka Enberg penb...@kernel.org wrote:
On Thu, May 5, 2011 at 10:02 AM, Ingo Molnar mi...@elte.hu wrote:
* Asias He asias.he...@gmail.com wrote:
With commit d7f0c07afeefa2d20739437306e4b8bb2853cf83 in master
(kvm tools: Fix virt_queue__set_used_elem)
I see this:
On Thu, May 5, 2011 at 10:47 AM, Ingo Molnar mi...@elte.hu wrote:
The build fails here too, in a similar way, on a 32-bit Fedora 14 box.
Curious. It works fine on my box. I think it's missing #include
asm/bitsperlong.h. I wonder why system.h isn't pulling that
itself...
asm/system.h is one
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:53:59 AM:
Not hope exactly. If the device is not ready, then
the packet is requeued. The main idea is to avoid
drops/stop/starts, etc.
Yes, I see that, definitely. I guess it's a win if the
interrupt takes at least a jiffy to
On Thu, 2011-05-05 at 10:52 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:47 AM, Ingo Molnar mi...@elte.hu wrote:
The build fails here too, in a similar way, on a 32-bit Fedora 14 box.
Curious. It works fine on my box. I think it's missing #include
asm/bitsperlong.h. I wonder why
Hi Marcelo,
Other than that, shouldnt reset accounting variables to init state on
write to GLOBAL_ENABLE_CFG / writes to main counter?
I'd suggest to initialize/reset the driftfix-related fields in the
'HPETTimer' structure (including the backlog of unaccounted ticks)
in the following
* Pekka Enberg penb...@kernel.org wrote:
asm/system.h is one of the messier kernel headers, so i'm not surprised it
has assymetric requirements on 64-bit and 32-bit systems.
So does including asm/bitsperlong.h before asm/system.h fix the problem
on 32-bit boxes? [...]
No, it's more
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
Paravirtual MSRs are properly cleared on reset now, and blindly clearing
the rest is questionable anyway (better address those one by one,
re-initializing their backing CPU state fields).
This can introduce a
On 2011-05-05 10:08, Avi Kivity wrote:
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
Paravirtual MSRs are properly cleared on reset now, and blindly clearing
the rest is questionable anyway (better address those one by one,
re-initializing their backing CPU
* Ingo Molnar mi...@elte.hu wrote:
I'm not entirely happy about how it has added dependent includes to virtio.c
but that's a property of this messy header file. Might be worth adding a
comment about that.
This block:
+#include linux/stringify.h
+#include linux/bitops.h
+#include
On 05/05/2011 11:11 AM, Jan Kiszka wrote:
On 2011-05-05 10:08, Avi Kivity wrote:
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
Paravirtual MSRs are properly cleared on reset now, and blindly clearing
the rest is questionable anyway (better address
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
All required bits for this cleanup of qemu-kvm are now upstream and
merged back - it's time to start the show. There are now 65 patches in
my queue, and I'm planning for at least 4 rounds.
This first part primarily aims at using upstream kvm_arch_init.
* Ingo Molnar mi...@elte.hu wrote:
* Ingo Molnar mi...@elte.hu wrote:
I'm not entirely happy about how it has added dependent includes to
virtio.c
but that's a property of this messy header file. Might be worth adding a
comment about that.
This block:
+#include
On 2011-05-05 10:16, Avi Kivity wrote:
On 05/05/2011 11:11 AM, Jan Kiszka wrote:
On 2011-05-05 10:08, Avi Kivity wrote:
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
Paravirtual MSRs are properly cleared on reset now, and blindly clearing
the rest is
On 2011-05-05 10:22, Avi Kivity wrote:
On 05/04/2011 10:43 PM, Jan Kiszka wrote:
All required bits for this cleanup of qemu-kvm are now upstream and
merged back - it's time to start the show. There are now 65 patches in
my queue, and I'm planning for at least 4 rounds.
This first part
On 05/05/2011 11:27 AM, Jan Kiszka wrote:
1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to
their power-on reset values.
Almost all: Which ones are CPU specific like the APIC_BASE?
Do you mean cpu specific as in smp or cpu specific as in cpu model?
If the former, we
On Wed, May 4, 2011 at 9:51 PM, Michael S. Tsirkin m...@redhat.com wrote:
With the new used_event and avail_event and features, both
host and guest need similar logic to check whether events are
enabled, so it helps to put the common code in the header.
Note that Xen has similar logic for
On 2011-05-05 10:33, Avi Kivity wrote:
On 05/05/2011 11:27 AM, Jan Kiszka wrote:
1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to
their power-on reset values.
Almost all: Which ones are CPU specific like the APIC_BASE?
Do you mean cpu specific as in smp or cpu
Hi Alex,
On 2011-01-28 01:45, Alex Williamson wrote:
On Thu, 2011-01-27 at 12:56 +0100, André Weidemann wrote:
Hi Alex,
On 26.01.2011 06:12, Alex Williamson wrote:
So while your initial results are promising, my guess is that you're
using card specific drivers and still need to consider
On 05/05/2011 11:44 AM, Jan Kiszka wrote:
On 2011-05-05 10:33, Avi Kivity wrote:
On 05/05/2011 11:27 AM, Jan Kiszka wrote:
1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to
their power-on reset values.
Almost all: Which ones are CPU specific like the APIC_BASE?
On Thu, May 05, 2011 at 09:34:46AM +0100, Stefan Hajnoczi wrote:
On Wed, May 4, 2011 at 9:51 PM, Michael S. Tsirkin m...@redhat.com wrote:
With the new used_event and avail_event and features, both
host and guest need similar logic to check whether events are
enabled, so it helps to put the
On Thu, May 05, 2011 at 01:33:14PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:53:59 AM:
Not hope exactly. If the device is not ready, then
the packet is requeued. The main idea is to avoid
drops/stop/starts, etc.
Yes, I see that,
On Wed, May 04, 2011 at 11:00:23PM +0300, Michael S. Tsirkin wrote:
On Wed, May 04, 2011 at 05:50:19PM +0300, Michael S. Tsirkin wrote:
@@ -185,11 +193,6 @@ int virtqueue_add_buf_gfp(struct virtque
if (vq-num_free out + in) {
pr_debug(Can't add buf len %i - avail = %i\n,
On 2011-05-05 10:53, Avi Kivity wrote:
On 05/05/2011 11:44 AM, Jan Kiszka wrote:
On 2011-05-05 10:33, Avi Kivity wrote:
On 05/05/2011 11:27 AM, Jan Kiszka wrote:
1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to
their power-on reset values.
Almost all: Which
On Wed, May 04, 2011 at 04:58:18PM -0500, Tom Lendacky wrote:
On Wednesday, May 04, 2011 03:51:47 PM Michael S. Tsirkin wrote:
Use the new avail_event feature to reduce the number
of exits from the guest.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
On Wed, May 04, 2011 at 04:56:09PM -0500, Tom Lendacky wrote:
On Wednesday, May 04, 2011 03:51:09 PM Michael S. Tsirkin wrote:
Define a new feature bit for the guest to utilize a used_event index
(like Xen) instead if a flag bit to enable/disable interrupts.
Signed-off-by: Michael S.
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:34:39 PM:
It shows that 2.9% of the time, the 1 jiffy was not enough
to free up space in the txq.
How common is it to free up space in *less than* 1 jiffy?
True, but the point is that the space freed is just
enough for 43 entries,
On Thu, May 05, 2011 at 03:13:43PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:34:39 PM:
It shows that 2.9% of the time, the 1 jiffy was not enough
to free up space in the txq.
How common is it to free up space in *less than* 1 jiffy?
There may be multiple disk images on a running guest,
each associated with a virtio-blk.
Move disk_image into virtio-blk in preperation for
multiple disk images.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h|1 -
Add support for multiple blk_devices by un-globalizing
the current blk_device and allow multiple blk_devices.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |2 +-
tools/kvm/mptable.c| 56 ++--
tools/kvm/virtio-blk.c | 193
Introduced new syntax for loading disk images.
Example:
./kvm run --image image1.img,ro --image image2.img
Will load image1.img with read only, and image2.img as
read/write.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/parse-options.h | 35
On 05/05/2011 12:32 PM, Jan Kiszka wrote:
If the former, we simply do the reset operation per-cpu. It's the
natural thing anyway.
Quite wasteful /wrt to memory given that the majority will be identical.
We're talking a few hundred bytes per cpu. If you want to save memory,
On 2011-05-05 12:22, Avi Kivity wrote:
On 05/05/2011 12:32 PM, Jan Kiszka wrote:
If the former, we simply do the reset operation per-cpu. It's
the
natural thing anyway.
Quite wasteful /wrt to memory given that the majority will be
identical.
We're talking a few
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 03:42:29 PM:
It shows that 2.9% of the time, the 1 jiffy was not enough
to free up space in the txq.
How common is it to free up space in *less than* 1 jiffy?
True,
Sorry, which statement do you say is true? That interrupt
On Thu, May 05, 2011 at 11:32:26AM +0200, Jan Kiszka wrote:
Of course, if we get a patch soon no one will ever see the
regression so
we can apply the series.
I will still require the usual testing and merging round via upstream
and back. Not sure when I'll be able to work on it,
On 05/05/2011 01:36 PM, Jan Kiszka wrote:
The problem is with hardware MSRs (PV MSRs are protected by cpuid, and
always disable themselves when zeroed).
Well, this doesn't change the problem of the existing code.
Right.
What I suggested wasn't zeroing them, but writing the value we
On 05/05/2011 02:22 PM, Gleb Natapov wrote:
We'll see, but I still do not share your concern regarding future
regressions when removing the fragile reset code.
Why do we rely on userspace to properly reset kernel component anyway?
We should introduce cpu/lapic/ioapic/pit/pic resets ASAP.
On Thu, May 05, 2011 at 02:58:27PM +0300, Avi Kivity wrote:
On 05/05/2011 02:22 PM, Gleb Natapov wrote:
We'll see, but I still do not share your concern regarding future
regressions when removing the fragile reset code.
Why do we rely on userspace to properly reset kernel component
On Wed, May 04, 2011 at 07:33:32PM +0530, Krishna Kumar wrote:
Changes:
1. Remove xmit notification
2. free_old_xmit_skbs() frees upto a limit to reduce tx jitter.
3. xmit_skb() precalculates the number of slots and checks if
that is available. It assumes that we are not using
On 2011-05-05 14:23, Gleb Natapov wrote:
On Thu, May 05, 2011 at 02:58:27PM +0300, Avi Kivity wrote:
On 05/05/2011 02:22 PM, Gleb Natapov wrote:
We'll see, but I still do not share your concern regarding future
regressions when removing the fragile reset code.
Why do we rely on userspace
On Thu, May 05, 2011 at 02:22:57PM +0300, Gleb Natapov wrote:
On Thu, May 05, 2011 at 11:32:26AM +0200, Jan Kiszka wrote:
Of course, if we get a patch soon no one will ever see the
regression so
we can apply the series.
I will still require the usual testing and merging
Hi all,
Have anyone tried to activate windows XP from a virtual machine booted with KVM
?
I am having trouble activating windows. the virtual machine is running smoothly
and can access the internet.
Thanks.
Majid.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On Thu, 2011-05-05 at 10:22 +0200, Ingo Molnar wrote:
* Ingo Molnar mi...@elte.hu wrote:
* Ingo Molnar mi...@elte.hu wrote:
I'm not entirely happy about how it has added dependent includes to
virtio.c
but that's a property of this messy header file. Might be worth adding a
Of course, on Debian Squeeze and Ubuntu 11.04, we activated both XP Sp3
x86 and W2K8R2 SP1 x64... No complains from M$...
I guess, the problem is not the Virtualisation.
Greetings,
Michael
On 05.05.2011 15:34, Majid Salame wrote:
Hi all,
Have anyone tried to activate windows XP from a
Hello to everybody,
I am working on KVM version 2.6.38
and I'm facing a new problem on an emulated instruction
whose implementation is already in kvm.
The error shows up after the emulation of the RET opcode (C3 Byte
Opcode).
When trying to emulate the instruction
at the address loaded after
Here are a couple of minor fixes suggested on list.
Applies on top of the previous patchset.
As before result pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
vhost-net-next-event-idx-v1
Michael S. Tsirkin (3):
virtio: fix avail event support
virtio_ring: check
make valid flag false, not true, on overrun
Reported-by: Tom Lendacky t...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_ring.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c
fix typo in a comment: size - side
Reported-by: Stefan Hajnoczi stefa...@gmail.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/virtio_ring.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
Nothing's wrong with vring_size as is, but it's nice
to check that the new field in the avail ring
won't overlow into the used ring.
Reported-by: Tom Lendacky t...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/virtio_ring.h |8 +++-
1 files
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:34:39 PM:
Do I need to apply all the patches and simply test?
Thanks,
- KK
Exactly. You can also try to tune the threshold
for interrupts as well.
I haven't tuned the threshhold, it is left it at 3/4. I ran
the new
Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
Oops, I sent my patch's test results for the 16K case.
The correct one is:
I/O size: 16K
# BW1 BW2 (%) SD1 SD2 (%)
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:34:39 PM:
Do I need to apply all the patches and simply test?
Thanks,
- KK
Exactly. You can also try to tune the threshold
for interrupts as well.
I
On 05/05/2011 10:45 PM, Pekka Enberg wrote:
On Thu, 2011-05-05 at 10:22 +0200, Ingo Molnar wrote:
* Ingo Molnar mi...@elte.hu wrote:
* Ingo Molnar mi...@elte.hu wrote:
I'm not entirely happy about how it has added dependent includes to
virtio.c
but that's a property of this messy header
On Thu, May 05, 2011 at 09:06:00PM +0530, Krishna Kumar2 wrote:
Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
Oops, I sent my patch's test results for the 16K case.
The correct one is:
I/O size: 16K
# BW1
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
Michael S. Tsirkin m...@redhat.com wrote on 05/05/2011 02:34:39 PM:
Do I need to apply all the patches and simply test?
Thanks,
- KK
Exactly. You can also try to tune the threshold
for interrupts as well.
I
On Thu, 2011-05-05 at 10:14 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:12 AM, Ingo Molnar mi...@elte.hu wrote:
another thing i noticed: the patch introduces some new uint_* usages.
Once things are fixed can we somehow kill that datatype intelligently, so
that
if new code uses
On Thu, May 05, 2011 at 10:33:01AM -0300, Marcelo Tosatti wrote:
On Thu, May 05, 2011 at 02:22:57PM +0300, Gleb Natapov wrote:
On Thu, May 05, 2011 at 11:32:26AM +0200, Jan Kiszka wrote:
Of course, if we get a patch soon no one will ever see the
regression so
we can apply
Clean uint*_t type from the code.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/8250-serial.c| 41 ---
tools/kvm/bios/e820.c | 16 +-
tools/kvm/disk-image.c | 24 +++---
Clean coding style and naming within virtio-blk.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio/blk.c | 133 +---
1 files changed, 70 insertions(+), 63 deletions(-)
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
Clean coding style and naming within virtio-console.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio/console.c | 69 +--
1 files changed, 34 insertions(+), 35 deletions(-)
diff --git a/tools/kvm/virtio/console.c
Clean coding style and naming within virtio-net.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio/net.c | 68
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
Clean coding style and naming within virtio-rng.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio/rng.c | 77 +++
1 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
On Thu, 5 May 2011, Sasha Levin wrote:
Clean uint*_t type from the code.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
Applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
* Sasha Levin levinsasha...@gmail.com wrote:
+struct rng_dev {
+ u8 status;
+ u16 config_vector;
int fd_rng;
I think you forgot the fd_rng - fd rename?
The cleanup
Please review, I hope I didn't miss anything. Testing is appereciated
and comments as well.
Thanks,
Cyrill
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
It's better than have them sprinkled in.c files. Note
that pin for ring device is changed so it no longer shared
with block device (it is done in a sake of simplicity).
Also comment style if a bit tuned up in virtio-pci.h
just to be consistent.
Reported-by: Ingo Molnar mi...@elte.hu
This also requires to tune up mptable code. Note the srcbusirq
need to follow specification convention, so we merge device
number and pin into one field inside mptable_set_default_int_src
helper.
Signed-off-by: Cyrill Gorcunov gorcu...@gmail.com
---
tools/kvm/include/kvm/virtio-pci-dev.h | 16
On 05/05/2011 11:06 PM, Cyrill Gorcunov wrote:
It's better than have them sprinkled in.c files. Note
that pin for ring device is changed so it no longer shared
with block device (it is done in a sake of simplicity).
Also comment style if a bit tuned up in virtio-pci.h
^^
Clean coding style and naming within virtio-rng.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio/rng.c | 79 +++
1 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
This patch cleans up some more style problems in virtio code.
Cc: Asias He asias.he...@gmail.com
Cc: Cyrill Gorcunov gorcu...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Prasad Joshi prasadjoshi...@gmail.com
Cc: Sasha Levin levinsasha...@gmail.com
Signed-off-by: Pekka Enberg penb...@kernel.org
Fix the loading of root device when no image name was
specified.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/kvm-run.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
index 2ff13d3..d5a952f 100644
---
I sent this out to the KVM/ARM mailing list, but figured KVM
developers may be interested as well.
Thanks,
Christoffer
-- Forwarded message --
From: Christoffer Dall cd...@cs.columbia.edu
Date: Thu, May 5, 2011 at 7:49 PM
Subject: Goal: Cortex-A15 support
To: android-virt
On 05/05/2011 11:06 PM, Cyrill Gorcunov wrote:
It's better than have them sprinkled in.c files. Note
that pin for ring device is changed so it no longer shared
with block device (it is done in a sake of simplicity).
Also comment style if a bit tuned up in virtio-pci.h
just to be consistent.
On Thu, 5 May 2011, Cyrill Gorcunov wrote:
This also requires to tune up mptable code. Note the srcbusirq
need to follow specification convention, so we merge device
number and pin into one field inside mptable_set_default_int_src
helper.
Signed-off-by: Cyrill Gorcunov gorcu...@gmail.com
This
On 05/06/2011 12:14 AM, Pekka Enberg wrote:
On Thu, 5 May 2011, Cyrill Gorcunov wrote:
This also requires to tune up mptable code. Note the srcbusirq
need to follow specification convention, so we merge device
number and pin into one field inside mptable_set_default_int_src
helper.
On Fri, 6 May 2011, Cyrill Gorcunov wrote:
This seems to break virtio drivers on my box.
Crap, thanks Pekka, I'll recheck. Drop this series for a while then.
I merged the first patch and fixed up PCI_VIRTIO_BLK_DEVNUM to 10.
Pekka
--
To unsubscribe from this list:
On 05/06/2011 12:16 AM, Pekka Enberg wrote:
On Fri, 6 May 2011, Cyrill Gorcunov wrote:
This seems to break virtio drivers on my box.
Crap, thanks Pekka, I'll recheck. Drop this series for a while then.
I merged the first patch and fixed up PCI_VIRTIO_BLK_DEVNUM to 10.
Pekka
On Fri, 2011-05-06 at 00:19 +0400, Cyrill Gorcunov wrote:
On 05/06/2011 12:16 AM, Pekka Enberg wrote:
On Fri, 6 May 2011, Cyrill Gorcunov wrote:
This seems to break virtio drivers on my box.
Crap, thanks Pekka, I'll recheck. Drop this series for a while then.
I merged the first
On Wed, 2011-05-04 at 16:13 -0700, Sridhar Samudrala wrote:
On Wed, 2011-05-04 at 01:14 -0700, Shirley Ma wrote:
Only when buffer size is greater than GOODCOPY_LEN (256), macvtap
enables zero-copy.
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/macvtap.c | 126
On Wed, 2011-05-04 at 16:13 -0700, Sridhar Samudrala wrote:
On Wed, 2011-05-04 at 00:55 -0700, Shirley Ma wrote:
Signed-off-by: Shirley Ma x...@us.ibm.com
---
include/linux/netdevice.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
* Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-05-05 at 10:14 +0300, Pekka Enberg wrote:
On Thu, May 5, 2011 at 10:12 AM, Ingo Molnar mi...@elte.hu wrote:
another thing i noticed: the patch introduces some new uint_* usages.
Once things are fixed can we somehow kill that
Hi, Jan
Thank you very much for your advice. That's helpful for me.
Hi,
the subject's tag (qemu-kvm) is misleading. This is actually targeting
the uq/master patch queue, i.e. the upstream kvm staging area.
If I want to submit a patch for the qemu-kvm-git, should I use
92 matches
Mail list logo
