Yang, Sheng wrote:
From a8ca7dd8f5fe0125e7b7d0a21f5caddacd754911 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 18 Aug 2008 11:04:22 +0800
Subject: [PATCH] KVM: Fix wrong KVM_GET_LAPIC
Which caused migration fail in recent commits.
Applied, thanks.
--
error
Yang, Sheng wrote:
From 50a27ca42a565579e78e3545ca097a65a88cbadd Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Wed, 13 Aug 2008 11:35:17 +0800
Subject: [PATCH] kvm: qemu: Add missing DEPLIBS in Makefile.target
Seems this flags is missing during merging long ago... And this
on Sat Aug 16 2008, Avi Kivity avi-AT-qumranet.com wrote:
In many ways kvm is a horrible choice. I'm not sure a name change is
possible at this stage, though.
I've thought of 'slice' (which rhymes nicely with some Qumranet
products, and so may not be the first choice for other kvm
Amit Shah wrote:
Even though we don't share irqs at the moment, we should ensure
regular user processes don't try to allocate system resources.
We check for capability to access IO devices (CAP_SYS_RAWIO) before
we request_irq on behalf of the guest.
Applied, thanks.
--
error compiling
Yang, Sheng wrote:
On Monday 18 August 2008 10:33:11 Anthony Liguori wrote:
Sebastian Herbszt wrote:
Jump to rombios before executing the halt loop.
Why? More importantly, why is this specific to KVM?
The bios copy AP boot up code to 0x1 now in KVM, so it can be
Sebastian Herbszt wrote:
Jump to rombios before executing the halt loop.
Applied, thanks.
.code16
smp_ap_boot_code_start:
+ cli
Redundant (but no harm done).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
Amit Shah wrote:
Fix typo in as-yet unused macro definition.
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 [EMAIL PROTECTED]
More majordomo info at
Stuart Sheldon wrote:
Another newbie question...
I've looks all over the place, and just can't seem to figure this out.
I want to build and install everything but the kernel modules from
release source. This will allow me to test against the vanilla modules
that come with the kernel source.
Anthony Liguori wrote:
With the latest GSO/csum offload patches, any guest using an unpatched version
of dhclient (any Ubuntu guest, for instance), will no longer be able to get
a DHCP address.
dhclient is actually at fault here. It uses AF_PACKET to receive DHCP responses
but does not check
From: Amit Shah [EMAIL PROTECTED]
... instead of using the pic and ioapic variants
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
arch/x86/kvm/i8254.c |6 ++
arch/x86/kvm/x86.c |8 +---
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/i8254.c
Herbert Xu wrote:
On Mon, Aug 18, 2008 at 02:06:46PM +0300, Avi Kivity wrote:
I still think that having the guests tell us that they can handle
it is the safest and most efficient way to proceed.
I thought this is a userspace problem? Can we fix this in the guest kernel?
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that call ethtool?
Well the idea is that only a fixed guest would even know about
Amit Shah wrote:
... instead of using the pic and ioapic variants
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 [EMAIL PROTECTED]
More majordomo info at
Jan Kiszka wrote:
There are more warnings, but one after the other. This patch addresses
all current warnings regarding unused variables in KVM userspace.
Applied (as well as the next patch), thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from
* On Monday 18 Aug 2008 17:08:20 Avi Kivity wrote:
Configuration problem?
Strange! Maybe the server I sent it from did something bad; I had sent another
patch just some time ago and that didn't get mangled.
Avi Kivity doesn't think he wrote:
From: Amit Shah [EMAIL PROTECTED]
... instead
Hi,
i want to make some test with qemu and pci passthrough with the VT-d feature.
In the linux-kernel git (http://git.kernel.org/;
linux/kernel/git/amit/kvm-userspace.git) repository i only found a 6 weeks old
version.
How can i get the latest version?
Where are the patches for the current
Hello,
* On Monday 18 Aug 2008 18:28:07 [EMAIL PROTECTED] wrote:
Hi,
i want to make some test with qemu and pci passthrough with the VT-d
feature.
In the linux-kernel git (http://git.kernel.org/;
linux/kernel/git/amit/kvm-userspace.git) repository i only found a 6 weeks
old version. How
Any objections to applying this series? It seems like the consensus is
that OHCI support is better long term but this series seems pretty sane
and self-contained.
Regards,
Anthony Liguori
Max Krasnyansky wrote:
This is an updated version of the USB patches I sent out yesterday.
It includes
Avi Kivity wrote:
Andrea Arcangeli wrote:
I'm more worried about the fact that with Anthony's plan ballooning
will be unusable for a long while on enterprise distros, as it will
take a while before they run on a =2.6.27 kernel. So I wonder if a
compact layer is worth it. But surely initially we
Max Krasnyansky wrote:
Guido Günther wrote:
What about /dev/bus/usb - it supports inotify fine on udev?
Yes it should since it's a regular filesystem.
I was thinking of this too since /proc/bus/usb is deprecated in favor of
/dev/bus/usb. If someone was willing to port QEMU to
Anthony Liguori writes ([Qemu-devel] Re: [PATCH 0/8] Various USB fixes and
improvements (update 2)):
Any objections to applying this series? It seems like the consensus is
that OHCI support is better long term but this series seems pretty sane
and self-contained.
I haven't reviewed the
/kernel subdir layout changed recently. Update gitignore to reflect this.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
diff --git a/.gitignore b/.gitignore
index 7422760..bb35cca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,19 +15,6 @@ qemu/qemu-img
qemu/qemu-nbd
*.ko
*.mod.c
On Saturday 16 August 2008 06:45:55 pm David Abrahams wrote:
on Sat Aug 16 2008, Glauber Costa glommer-AT-gmail.com wrote:
Really, everyone types out that long phrase when asking questions?
No, I type kernel kvm or do kvm -switch to remove pages that talk about
KVM switches. I have also
Anthony Liguori wrote:
Max Krasnyansky wrote:
Guido Günther wrote:
What about /dev/bus/usb - it supports inotify fine on udev?
Yes it should since it's a regular filesystem.
I was thinking of this too since /proc/bus/usb is deprecated in favor of
/dev/bus/usb. If someone was
Javier Guerra wrote:
On Fri, Aug 15, 2008 at 1:24 PM, Max Krasnyansky [EMAIL PROTECTED] wrote:
btw Interface to HAL might still be useful in general to monitor other device
classes that we may want to automatically assign to the VMs. So I'll play
around with that too (some day :)).
what
Paul Brook wrote:
Given that OHCI is much more complex than UHCI (both the code and the spec)
I decided to give up on OHCI, at least for now. I noticed Codesourcery
copyright on OHCI. Did you have anything to do with the OHCI implementation?
Yes, I wrote the current OHCI support, based on some
On Mon, Aug 18, 2008 at 1:21 PM, Max Krasnyansky [EMAIL PROTECTED] wrote:
Javier Guerra wrote:
what about doing it the other way around? that is, setting udev
scripts that notify KVM of the hardware changes.
That seems a bit odd. What if you have more than one QEMU instance and
stuff.
Javier Guerra wrote:
there has to be some policy in place to redirect USB devices to each
QEMU instance, maybe at startup it could reserve a node in the USB
device tree (an USB controller, or maybe a port in a hub). when
invoked by udev, some script would consult those reservations and pick
Anthony Liguori wrote:
Any objections to applying this series? It seems like the consensus is
that OHCI support is better long term but this series seems pretty sane
and self-contained.
I'm actually having seconds thought on the OHCI vs UHCI. You probably
saw my reply to Paul. New UHCI code
The patch adds in/out instructions to the x86 emulator.
The instruction was encountered while running the BIOS while using
the invalid guest state emulation patch.
Signed-off-by: Mohammed Gamal [EMAIL PROTECTED]
---
arch/x86/kvm/x86_emulate.c | 35 +--
1 files
On Monday 18 August 2008 21:44:25 Herbert Xu wrote:
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that call ethtool?
Well the
On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote:
For those not following closely: We already have a method for the
guest to accept or reject features. Our problem is that the guest
is already accepting the CSUM feature: but one critical userspace
app (dhcp-client) can't
On Tuesday 19 August 2008 13:17:57 Chris Wedgwood wrote:
On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote:
For those not following closely: We already have a method for the
guest to accept or reject features. Our problem is that the guest
is already accepting the CSUM feature:
On Tue, Aug 19, 2008 at 02:41:01PM +1000, Rusty Russell wrote:
They need to do both. This way if they don't, it still works, but
networking is at a penalty (no CSUM offload).
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented
On Mon, Aug 18, 2008 at 10:13:55PM -0700, Chris Wedgwood wrote:
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented short lifetime (if it
really must go in)?
All we need is a simple toggle to disable checksum offload. Every
NIC
On Tue, Aug 19, 2008 at 03:17:08PM +1000, Herbert Xu wrote:
All we need is a simple toggle to disable checksum offload. Every
NIC that offers receive checksum offload allows it to be disabled.
virtio shouldn't be any different.
So why CSUM2 and not an ethtool interface then?
--
To
36 matches
Mail list logo
