On Thu, Feb 05, 2009 at 02:37:07PM +0200, Avi Kivity wrote:
>
> I believe that copyless networking is absolutely essential.
I used to think it was important, but I'm now of the opinion
that it's quite useless for virtualisation as it stands.
> For transmit, copyless is needed to properly support
Now that virtio-net knows what packets the guest wants to see, we
can start moving the filtering down the stack. This patch adds
an interface to set the software filter in the tap device. It's
fairly limited, but we can back it up with our own filtering if it
overflows.
Here are a couple issues
Avi Kivity writes:
> - add a watchpoint to break when the value of gs:[0x30] changes
It seems that the problem can be reproduced by compiling the following
simple program using cygwin's gcc. The program crashes on w2k3-amd64
on kvm-83 on core2-duo, and it does not crash on the same w2k3-amd64
i
Alex Williamson wrote:
The status register should probably be saved since its guest visible.
Also add a little bit if infrastructure for handling various save
revisions.
Signed-off-by: Alex Williamson
Applied all. Thanks.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send
heinz wrote:
This kernel does support kvm and the prement patch to make it pretty
good for real time things.
A kvm virtual machine is running for example windows xp with some WPF
gui. That would be a nice solution,
and for many problems - including those windows gui guys needing real
time as we
David S. Ahern wrote:
>
> Stefano Stabellini wrote:
>> Michael Tokarev wrote:
>>
>>> Other than that, an.. excellent idea, I wanted to propose
>>> just that when I first saw all this stuff, but was somewhat
>>> afraid. And I *think* there's at least *some* sense. Qemu
>>> is a CPU emulator and
Ingo Molnar wrote:
* Glauber Costa wrote:
+char * __cpuinit hypervisor_str(struct cpuinfo_x86 *c)
+{
+ if (c->x86_hyper_vendor == X86_HYPER_VENDOR_VMWARE)
+ return "VMWare";
+ else
+ return "none";
+}
i'd suggest these variants instead:
virtu
* Ingo Molnar (mi...@elte.hu) wrote:
> virtualization: Linux guest
That's confusing. Meaning lguest? These are all Linux guests ;-)
--
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.ke
* Glauber Costa wrote:
> +char * __cpuinit hypervisor_str(struct cpuinfo_x86 *c)
> +{
> + if (c->x86_hyper_vendor == X86_HYPER_VENDOR_VMWARE)
> + return "VMWare";
> + else
> + return "none";
> +}
i'd suggest these variants instead:
virtualization:native
On Thu, Feb 05, 2009 at 10:52:07AM -0800, Chris Wright wrote:
> * Glauber Costa (glom...@redhat.com) wrote:
> > This discussion happened some days ago in kvm list.
> > We believe it's useful to advertise hypervisor information
> > somewhere. /proc/cpuinfo appears as one good candidate.
>
> What's
I am all for it.
Just one nit, below.
>
> +char * __cpuinit hypervisor_str(struct cpuinfo_x86 *c)
> +{
> + if (c->x86_hyper_vendor == X86_HYPER_VENDOR_VMWARE)
> + return "VMWare";
Better to have "VMware" string instead.
Thanks,
Alok
--
To unsubscribe from this list: send the
* Mark McLoughlin (mar...@redhat.com) wrote:
> kvm->slots_lock is outer to kvm->lock, so take slots_lock
> in kvm_vm_ioctl_assign_device() before taking kvm->lock,
> rather than taking it in kvm_iommu_map_memslots().
stable? maint/2.6.29?
--
To unsubscribe from this list: send the line "unsubscri
* Glauber Costa (glom...@redhat.com) wrote:
> This discussion happened some days ago in kvm list.
> We believe it's useful to advertise hypervisor information
> somewhere. /proc/cpuinfo appears as one good candidate.
What's wrong with /sys/hypervisor? That's what it's there for.
thanks,
-chris
-
From: Glauber Costa
KVM has a specific cpuid signature, for a long time now. It's currently
used in the kernel to advertise the possible availability of paravirt
functions, but it's safe to assume that any reasonably recent kvm
hypervisor will sign cpuid this way, regardless of any pv capability.
From: Glauber Costa
It is useful to easily grab information about whether or not
we're running on top of a hypervisor. And in case affirmative,
which one.
This patch shows it in a newly added "hypervisor" field to cpuinfo.
This seems to me like the best suited place for this.
We currently diffe
This discussion happened some days ago in kvm list.
We believe it's useful to advertise hypervisor information
somewhere. /proc/cpuinfo appears as one good candidate.
This patch shows this information for vmware, kvm, and the
string "none", otherwise. (someone would have to do it for xen,
and poss
Stefano Stabellini wrote:
> Michael Tokarev wrote:
>
>> Other than that, an.. excellent idea, I wanted to propose
>> just that when I first saw all this stuff, but was somewhat
>> afraid. And I *think* there's at least *some* sense. Qemu
>> is a CPU emulator and may work on another arch where
Michael Tokarev wrote:
> After some debugging and debugging, with a help
> Hollis Blanchard on #...@freenode, I discovered
> that kvm (or, rather, qemu) does not work correctly
> with serial ports, at least on linux. One problem
> report has already here, author Cc'd -- see e.g.
> http://marc.info
kvm->slots_lock is outer to kvm->lock, so take slots_lock
in kvm_vm_ioctl_assign_device() before taking kvm->lock,
rather than taking it in kvm_iommu_map_memslots().
Signed-off-by: Mark McLoughlin
---
virt/kvm/iommu.c|6 ++
virt/kvm/kvm_main.c |3 +++
2 files changed, 5 insertion
KVM common code should'nt try to create the same virtual cpu twice.
In case of s390, it crashes badly in kvm_arch_vcpu_create.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
---
virt/kvm/kvm_main.c |3 +++
1 file changed, 3 insertions(+)
Index: kvm/virt/kvm/kvm_main.c
=
Am Thu, 5 Feb 2009 17:05:01 +0100
schrieb Carsten Otte :
> KVM common code should'nt try to create the same virtual cpu twice.
> In case of s390, it crashes badly in kvm_arch_vcpu_create.
This patch is broken, will refresh it. Please do _NOT_ apply (!)
--
To unsubscribe from this list: send the lin
Marcelo Tosatti wrote:
Sorry, still rejects horribly. What did you generate this against?
The kernel/ part seems unrelated.
This was merged through the kvm-devel branch (unless you dropped it).
Right, so that's why it rejected.
I even saw it in the log when I tried to find why it
On Thu, Feb 05, 2009 at 05:42:34PM +0200, Avi Kivity wrote:
> john cooper wrote:
>> Avi Kivity wrote:
>>> john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
th
KVM common code should'nt try to create the same virtual cpu twice.
In case of s390, it crashes badly in kvm_arch_vcpu_create.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
---
virt/kvm/kvm_main.c |3 +++
1 file changed, 3 insertions(+)
Index: kvm/virt/kvm/kvm_main.c
=
Avi Kivity wrote:
> Alexander Graf wrote:
>> Most distributions use an executable name of qemu-kvm for kvm's
>> qemu version.
>> This is mostly because Qemu was there before and there usually is
>> a package with a binary called qemu-system-x86_64 already.
>>
>> In order to not confuse people why d
This check verifies that the guest we're trying to run in KVM_RUN
has some memory assigned to it. It enters an endless exception
loop if this is not the case.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
---
arch/s390/kvm/kvm-s390.c |6 ++
1 file changed, 6 insertions(+)
Inde
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for the virtual cpus. In order to do that, we
use the vcpu->mutex to lock out kvm_run and friends.
john cooper wrote:
Avi Kivity wrote:
john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for refer
Alexander Graf wrote:
Most distributions use an executable name of qemu-kvm for kvm's
qemu version.
This is mostly because Qemu was there before and there usually is
a package with a binary called qemu-system-x86_64 already.
In order to not confuse people why distributions do things so
different
All,
I've been trying to track down this problem with starting X on a 32-bit
guest on a 64-bit host, and I've hit a bit of a wall. Let me describe the
setup:
Host: AMD Barcelona machine, 16GB memory, 8 cores, running 2.6.29-rc2,
kvm-userspace 3f7cba35281a5b2dba008179a4979d737105574d
Guest:
Avi Kivity wrote:
Chris Wright wrote:
There's been a number of different discussions re: getting copyless
virtio
net (esp. for KVM). This is just a poke in that general direction to
stir the discussion. I'm interested to hear current thoughts
I believe that copyless networking is absolutely
Hi KVM guys,
reading the kvm doku and think about real time together with windrivers
anouncement of a real time hypervisor I had an idea.
Not sure if this is possible, but I am sure you guys will have an answer
to that:
I can think of a box, running a minimal linux (without any display,
seri
Generate interrupt only if corespondent EN bit is set.
Signed-off-by: Gleb Natapov
---
qemu/hw/acpi.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index c2c60ad..fcb02a5 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -814,
Signed-off-by: Gleb Natapov
---
qemu/hw/acpi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index f94ab22..1d1a6b5 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -746,7 +746,7 @@ DefinitionBlock (
Name(
1) Disabled processor's _STA method should return 0 (this fixes Vista's
BSOD on resuming after hibernate problem)
2) Disabled processor's _MAT method should return disabled MADT entry
instead of 0 (this fixes Linux kernel complains during boot)
3) Extend bitmask of hot pluggable CPUs to be 25
For STS register bit are cleared by writing 1 into it.
Signed-off-by: Gleb Natapov
---
qemu/hw/acpi.c | 43 +++
1 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index b998225..7074166 100644
--- a/qemu/hw/
Gleb Natapov wrote:
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
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
Jan Kiszka wrote:
Jan Kiszka wrote:
When disabling SMP on kernels older than 2.6.27, the compat wrapping
fails due to unresolved SMP dependencies. This patch fixes the build.
Still applies, still required.
Applied, thanks.
--
error compiling committee.c: too many arguments to fun
Jan Kiszka wrote:
pci_dev.msi_enabled was introduced in 2.6.18, thus building against
older kernels now fails. Fix via a compat wrapper that reads directly
from the PCI config space.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
Chris Wright wrote:
There's been a number of different discussions re: getting copyless virtio
net (esp. for KVM). This is just a poke in that general direction to
stir the discussion. I'm interested to hear current thoughts
I believe that copyless networking is absolutely essential.
For tra
40 matches
Mail list logo