From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/kvm/scripts/make-release b/kvm/scripts/make-release
index 3b1dccf..11d9c27 100755
--- a/kvm/scripts/make-release
+++ b/kvm/scripts/make-release
@@ -45,6 +45,13 @@ tarball=$releasedir/$name.tar
cd $(dirname
From: Avi Kivity a...@redhat.com
The first such option rom will load at address 0, which isn't very nice,
and the second will report a conflict and abort, which is horrible.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/hw/loader.c b/hw/loader.c
index 2ceb8eb..eef385e 100644
---
From: Alexander Graf ag...@suse.de
To retreive device and vendor ID from a PCI device, we need to read a
sysfs file. That code is currently hand written at least two times,
the later patch introducing two more calls.
So let's move that out to a function.
Signed-off-by: Alexander Graf
From: Alexander Graf ag...@suse.de
When using -pcidevice on a device that is already in use by a kernel driver
all the user gets is the following (very useful) information:
Failed to assign device 04:00.0 : Device or resource busy
Failed to deassign device 04:00.0 : Invalid argument
Error
From: Avi Kivity a...@redhat.com
It doesn't exist outside x86, and breaks the build. Move it to
cpu_synchronize_state() instead (only reading, not writing).
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/monitor.c b/monitor.c
index 5a9fae6..6ff6e1f 100644
--- a/monitor.c
+++
From: Alexander Graf ag...@suse.de
We're using a switch table to find the irqprio that belongs to a specific
interrupt vector. This table is part of the interrupt inject logic.
Since we'll add a new function to stop interrupts, let's move this table
out of the injection logic into a separate
From: Alexander Graf ag...@suse.de
Because we now emulate the DEC interrupt according to real life behavior,
there's no need to keep the AGGRESSIVE_DEC hack around.
Let's just remove it.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Acked-by: Hollis Blanchard hol...@penguinppc.org
From: Alexander Graf ag...@suse.de
We treated the DEC interrupt like an edge based one. This is not true for
Book3s. The DEC keeps firing until mtdec is issued again and thus clears
the interrupt line.
So let's implement this logic in KVM too. This patch moves the line clearing
from the firing
From: Alexander Graf ag...@suse.de
Progress on KVM for Embedded PowerPC has stalled, but for Book3S there's quite
a lot of work to do and going on.
So in agreement with Hollis and Avi, we should switch maintainers for PowerPC.
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Hollis
From: Alexander Graf ag...@suse.de
Embedded PowerPC KVM has an exit timing implementation to track and evaluate
how much time was spent in which exit path.
For Book3S, we don't implement it. So let's not expose it as a config option
either.
Signed-off-by: Alexander Graf ag...@suse.de
On 12/22/2009 12:21 AM, Mikolaj Kucharski wrote:
On Mon, Dec 21, 2009 at 09:22:52AM +0200, Gleb Natapov wrote:
I have personal interest in resolving RedHat's bz #508801, unfortunately
I cannot do that myself, so I wanted to ask on the list for help, but now
I'm confused where should I go.
On 12/21/2009 09:21 PM, Alexander Graf wrote:
We currently have an ugly hack called AGGRESSIVE_DEC that makes the Decrementor
either work well for PPC32 or PPC64 targets.
This patchset removes that hack, bringing the decrementor implementation closer
to real hardware.
Applied, thanks.
--
On 12/20/2009 11:24 PM, Alexander Graf wrote:
Embedded PowerPC KVM has an exit timing implementation to track and evaluate
how much time was spent in which exit path.
For Book3S, we don't implement it. So let's not expose it as a config option
either.
Applied, thanks.
--
error compiling
On 12/20/2009 11:24 PM, Alexander Graf wrote:
Progress on KVM for Embedded PowerPC has stalled, but for Book3S there's quite
a lot of work to do and going on.
So in agreement with Hollis and Avi, we should switch maintainers for PowerPC.
I'll still demand Acks from Hollis for code that changes
On 12/17/2009 05:04 PM, Alexander Graf wrote:
While trying out I stumbled across several issues in the device assignment
code.
This set addresses the most major ones. Namely allowing passthrough of non page
aligned BAR region (like on lpfc) and telling users what to do when their
device is in
ROM BAR can be handled same as regular BAR:
load_option_roms utility will take care of
copying it to RAM as appropriate.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
This patch applies on top of agraf's one,
it takes care of non-page aligned ROM BARs as well:
they mostly are taken care
Hi,
I've switched from -0.11.0 to -0.12 and from 2.6.31.6 to 2.6.32.2 to try the
new virtio-memory-API introduced in latest libvirt from git. I can start VMs
f.e. by kvm -cdrom $someiso --enable-kvm but my domain configs to not work
anymore.
Domain config: http://pastebin.com/f66324669
On Tuesday 22 December 2009 13:02:28 Thomas Treutner wrote:
Hi,
I've switched from -0.11.0 to -0.12 and from 2.6.31.6 to 2.6.32.2 to try
the new virtio-memory-API introduced in latest libvirt from git. I can
start VMs f.e. by kvm -cdrom $someiso --enable-kvm but my domain configs to
not work
On Tue, Dec 22, 2009 at 01:05:23PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
ROM BAR can be handled same as regular BAR:
load_option_roms utility will take care of
copying it to RAM as appropriate.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
This patch
qemu-kvm-0.12.1.1 is now available. This release is is based on the
upstream qemu 0.12.1, plus kvm-specific enhancements. Please see the
original qemu 0.12.1 release announcement for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by
sorry to bring bad news, but it still doesn't compile (at least for me):
[r...@vmdev03 qemu-kvm-0.12.1.1]# make
LINK x86_64-softmmu/qemu-system-x86_64
machine.o: In function `cpu_pre_save':
/usr/src/redhat/BUILD/qemu-kvm-0.12.1.1/target-i386/machine.c:326: undefined
reference to
On 12/22/2009 03:35 PM, Nikola Ciprich wrote:
sorry to bring bad news, but it still doesn't compile (at least for me):
[r...@vmdev03 qemu-kvm-0.12.1.1]# make
LINK x86_64-softmmu/qemu-system-x86_64
machine.o: In function `cpu_pre_save':
CentOS5, all packages updated.
But I just noticed build fails only when configured with multiple targets,
including some more exotic (based on fedora spec).
building just using x86_64-softmmu works fine for me.
n.
On Tue, Dec 22, 2009 at 03:43:32PM +0200, Avi Kivity wrote:
On 12/22/2009 03:35
On 12/22/2009 04:07 PM, Nikola Ciprich wrote:
CentOS5, all packages updated.
But I just noticed build fails only when configured with multiple targets,
including some more exotic (based on fedora spec).
building just using x86_64-softmmu works fine for me.
Okay, so at least it works out of
On Tue, Dec 22, 2009 at 09:15:57AM +0200, Gleb Natapov wrote:
On Mon, Dec 21, 2009 at 10:21:14PM +, Mikolaj Kucharski wrote:
On Mon, Dec 21, 2009 at 09:22:52AM +0200, Gleb Natapov wrote:
I have personal interest in resolving RedHat's bz #508801, unfortunately
I cannot do that
On Tue, Dec 22, 2009 at 02:34:42PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 22, 2009 at 01:05:23PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
ROM BAR can be handled same as regular BAR:
load_option_roms utility will take care of
copying
On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote:
I'm not sure the BIOS is the only one executing ROMs. If it is, then I'm
good with the change.
Maybe it'd make sense to also add a read only flag so we don't
accidently try to write to the ROM region with slow_map.
Alex
Correct: I think
Avi Kivity wrote:
On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote:
I'm not sure the BIOS is the only one executing ROMs. If it is, then
I'm
good with the change.
Maybe it'd make sense to also add a read only flag so we don't
accidently try to write to the ROM region with slow_map.
Alex
Avi Kivity wrote:
On 12/22/2009 05:36 PM, Alexander Graf wrote:
Is there a way to trap this and fprintf something?
I don't think so. KVM will just trap on execution outside of RAM and
either fail badly or throw something bad into the guest. MMIO access
works by analyzing the
On 12/22/2009 05:41 PM, Alexander Graf wrote:
We could certainly extend emulate.c to fetch instruction bytes from
userspace. It uses -read_std() now, so we'd need to switch to
-read_emulated() and add appropriate buffering.
I thought the policy on emulate.c was to not have a full
On Tuesday 22 December 2009 04:31:32 pm Anthony Liguori wrote:
I think the comparison would be if someone submitted a second e1000
driver that happened to do better on one netperf test than the current
e1000 driver.
You can argue, hey, choice is good, let's let a user choose if they want
On Tue, Dec 22, 2009 at 05:00:52PM +0100, Alexander Graf wrote:
Avi Kivity wrote:
On 12/22/2009 05:41 PM, Alexander Graf wrote:
We could certainly extend emulate.c to fetch instruction bytes from
userspace. It uses -read_std() now, so we'd need to switch to
-read_emulated() and add
Michael S. Tsirkin wrote:
On Tue, Dec 22, 2009 at 05:00:52PM +0100, Alexander Graf wrote:
Avi Kivity wrote:
On 12/22/2009 05:41 PM, Alexander Graf wrote:
We could certainly extend emulate.c to fetch instruction bytes from
userspace. It uses -read_std() now, so we'd need to
On 12/22/2009 06:21 PM, Andi Kleen wrote:
So far, the only actual technical advantage I've seen is that vbus avoids
EOI exits.
The technical advantage is that it's significantly faster today.
Maybe your proposed alternative is as fast, or maybe it's not. Who knows?
We're working on
On Sun, Dec 20, 2009 at 11:30:00AM +0200, Avi Kivity wrote:
On 12/18/2009 10:48 AM, Sheng Yang wrote:
Applied all, thanks.
Need to save/restore MSR_TSC_AUX in qemu-kvm.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
This looks like an error case, but it's just a special case to shutdown
the backend. Clarify with a comment.
Signed-off-by: Chris Wright chr...@redhat.com
---
drivers/vhost/net.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
On 12/22/2009 07:26 PM, Marcelo Tosatti wrote:
On Sun, Dec 20, 2009 at 11:30:00AM +0200, Avi Kivity wrote:
On 12/18/2009 10:48 AM, Sheng Yang wrote:
Applied all, thanks.
Need to save/restore MSR_TSC_AUX in qemu-kvm.
Should be automatic. After all, we expose all the MSR list,
On 12/22/2009 07:36 PM, Gregory Haskins wrote:
Gregory, it would be nice if you worked _much_ harder with the KVM folks
before giving up.
I think the 5+ months that I politely tried to convince the KVM folks
that this was a good idea was pretty generous of my employer. The KVM
On 12/22/09 1:53 PM, Avi Kivity wrote:
On 12/22/2009 07:36 PM, Gregory Haskins wrote:
Gregory, it would be nice if you worked _much_ harder with the KVM folks
before giving up.
I think the 5+ months that I politely tried to convince the KVM folks
that this was a good idea was pretty
Trivial change, just for readability. The filp is not installed on
failure, so the current code is not incorrect (also vhost_dev_init
currently has no failure case). This just treats setting f-private_data
as something with global scope (sure, true only after fd_install).
Signed-off-by: Chris
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not
reply.
BTW: the ioeventfd issue just fell through the cracks, so sorry about
that. Note that I have no specific issue with irqfd ever since the
lockless IRQ injection code was
On 12/22/2009 09:15 PM, Gregory Haskins wrote:
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not
reply.
BTW: the ioeventfd issue just fell through the cracks, so sorry about
that. Note that I have no specific issue
On 12/22/09 2:32 PM, Gregory Haskins wrote:
On 12/22/09 2:25 PM, Avi Kivity wrote:
If you're not doing something pretty minor, you're better of waking up a
thread (perhaps _sync if you want to keep on the same cpu). With the
new user return notifier thingie, that's pretty cheap.
We have
On 12/22/09 2:38 PM, Avi Kivity wrote:
On 12/22/2009 09:32 PM, Gregory Haskins wrote:
xinterface, as it turns out, is a great KVM interface for me and easy to
extend, all without conflicting with the changes in upstream. The old
way was via the kvm ioctl interface, but that sucked as the ABI
On 12/22/2009 09:32 PM, Gregory Haskins wrote:
Besides, Davide has
already expressed dissatisfaction with the KVM-isms creeping into
eventfd, so its not likely to ever be accepted regardless of your own
disposition.
Why don't you duplicate eventfd, then, should be easier than duplicating
On 12/22/2009 09:41 PM, Gregory Haskins wrote:
It means that kvm locking suddenly affects more of the kernel.
Thats ok. This would only be w.r.t. devices that are bound to the KVM
instance anyway, so they better know what they are doing (and they do).
It's okay to the author of
On 12/22/09 2:43 PM, Avi Kivity wrote:
On 12/22/2009 09:41 PM, Gregory Haskins wrote:
It means that kvm locking suddenly affects more of the kernel.
Thats ok. This would only be w.r.t. devices that are bound to the KVM
instance anyway, so they better know what they are doing (and
On 12/22/09 2:39 PM, Davide Libenzi wrote:
On Tue, 22 Dec 2009, Gregory Haskins wrote:
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did
not reply.
BTW: the ioeventfd issue just fell through the cracks, so sorry about
that.
On 12/21/09 7:12 PM, Anthony Liguori wrote:
On 12/21/2009 11:44 AM, Gregory Haskins wrote:
Well, surely something like SR-IOV is moving in that direction, no?
Not really, but that's a different discussion.
Ok, but my general point still stands. At some level, some crafty
hardware
On 12/22/2009 11:33 AM, Andi Kleen wrote:
We're not talking about vaporware. vhost-net exists.
Is it as fast as the alacrityvm setup then e.g. for network traffic?
Last I heard the first could do wirespeed 10Gbit/s on standard hardware.
I'm very wary of any such claims. As far as
On Tue, 22 Dec 2009, Gregory Haskins wrote:
On 12/22/09 2:39 PM, Davide Libenzi wrote:
On Tue, 22 Dec 2009, Gregory Haskins wrote:
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did
not reply.
BTW: the ioeventfd issue
On Tue, Dec 22, 2009 at 12:36, Gregory Haskins
gregory.hask...@gmail.com wrote:
On 12/22/09 2:57 AM, Ingo Molnar wrote:
* Gregory Haskins gregory.hask...@gmail.com wrote:
Actually, these patches have nothing to do with the KVM folks. [...]
That claim is curious to me - the AlacrityVM host
On Tue, 22 Dec 2009 10:09:33 pm Michael S. Tsirkin wrote:
From: David Stevens dlstev...@us.ibm.com
Subject: vhost: fix high 32 bit in FEATURES ioctls
Thanks, applied.
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
* Anthony Liguori anth...@codemonkey.ws wrote:
On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote:
new e1000 driver is more superior in architecture and do the required
work to make the new e1000 driver a full replacement for the old one.
Right, like everyone actually does things this
On 12/21/2009 09:21 PM, Alexander Graf wrote:
We currently have an ugly hack called AGGRESSIVE_DEC that makes the Decrementor
either work well for PPC32 or PPC64 targets.
This patchset removes that hack, bringing the decrementor implementation closer
to real hardware.
Applied, thanks.
--
On 12/20/2009 11:24 PM, Alexander Graf wrote:
Progress on KVM for Embedded PowerPC has stalled, but for Book3S there's quite
a lot of work to do and going on.
So in agreement with Hollis and Avi, we should switch maintainers for PowerPC.
I'll still demand Acks from Hollis for code that changes
56 matches
Mail list logo
