Am 15.12.2009 um 05:08 schrieb Zachary Amsden zams...@redhat.com:
This set of patches builds the infrastructure to do both passthrough
and
intercept based virtualization of TSC in KVM.
Would you mind to give a high level overview of what exactly you're
doing? So far I've only glimpsed
On Sun, 2009-12-13 at 13:08 +0200, Michael S. Tsirkin wrote:
Do not cast away void*.
This initialization above looks very strange: in
fact only one of skb, page makes sense.
So I think you should either get rid of both page and
skb variables (routines such as give_pages get page *
so they
Because kenrel prctl implementation checks whether arg4 and arg5 are 0
for PR_MCE_KILL, qmeu-kvm should invoke prctl syscall as that.
Reported-by: Max Asbock masb...@linux.vnet.ibm.com
Signed-off-by: Huang Ying ying.hu...@intel.com
---
qemu-kvm.c |2 +-
1 file changed, 1 insertion(+), 1
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed
two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it
(tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't
work. DHCP doesn't work, if you
On 12/15/2009 10:48 AM, Huang Ying wrote:
Because kenrel prctl implementation checks whether arg4 and arg5 are 0
for PR_MCE_KILL, qmeu-kvm should invoke prctl syscall as that.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
(copying qemu-devel)
On 12/15/2009 10:28 AM, Ingmar Schraub wrote:
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed
two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it
(tested with Ubuntu Karmic 64-Bit and
On 12/14/2009 11:58 PM, Dustin Kirkland wrote:
I'm working on the packaging updates for Ubuntu Lucid, and I'm having
trouble with the BIOS bits of qemu-kvm.
It seems that a fair amount of the BIOS submodules are missing.
The roms/ tree is basically empty.
Well, binaries are shipped,
On 12/15/2009 07:29 AM, Sheng Yang wrote:
We don't support these instructions, but guest can execute them even if the
feature('monitor') haven't been exposed in CPUID. So we would trap and inject
a #UD if guest try this way.
Applied, and queued for stable. Thanks.
--
error compiling
On 12/15/2009 09:36 AM, Alexander Graf wrote:
On 15.12.2009, at 06:29, Sheng Yang wrote:
We don't support these instructions, but guest can execute them even if the
feature('monitor') haven't been exposed in CPUID. So we would trap and inject
a #UD if guest try this way.
Wouldn't it
On 12/15/2009 07:29 AM, Sheng Yang wrote:
We don't support these instructions, but guest can execute them even if the
feature('monitor') haven't been exposed in CPUID. So we would trap and inject
a #UD if guest try this way.
CPU_BASED_MOV_DR_EXITING |
On Mon, Dec 14, 2009 at 10:48:49PM -0500, Kevin O'Connor wrote:
There is now a mailing list for discussions on SeaBIOS. To join the
mailing list, please visit:
http://www.seabios.org/mailman/listinfo/seabios
Mails can be sent to seab...@seabios.org. To reduce spam, non-member
posts to
On 12/15/2009 04:28 AM, Sheng Yang wrote:
One possible order is:
KVM_CREATE_IRQCHIP ioctl(took kvm-lock) - kvm_iobus_register_dev() -
down_write(kvm-slots_lock).
The other one is in kvm_vm_ioctl_assign_device(), which take kvm-slots_lock
first, then kvm-lock.
Update the comment of lock order
Avi Kivity wrote:
On 12/15/2009 09:36 AM, Alexander Graf wrote:
On 15.12.2009, at 06:29, Sheng Yang wrote:
We don't support these instructions, but guest can execute them even
if the
feature('monitor') haven't been exposed in CPUID. So we would trap
and inject
a #UD if guest try this
On 12/15/2009 03:05 AM, Chris Wright wrote:
Fix build when !CONFIG_EVENTFD
CCcompatfd.o
compatfd.c: In function ‘qemu_eventfd’:
compatfd.c:137: error: ‘ret’ undeclared (first use in this function)
compatfd.c:137: error: (Each undeclared identifier is reported only once
compatfd.c:137:
On Tuesday, 15 December 2009 09:28:38 +0100,
Ingmar Schraub wrote:
Hi,
Hi, Ingmar.
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed
two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it
(tested with Ubuntu
Fix compile without eventfd.
Signed-off-by: Bernhard Held bh...@mgpi.de
---
compatfd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- qemu-kvm-0.12.0-rc2/compatfd.c
+++ qemu-kvm-0.12.0-rc2/compatfd.c
@@ -118,9 +118,9 @@
int qemu_eventfd(int *fds)
{
-#if
On 12/15/2009 11:36 AM, Alexander Graf wrote:
You'll need to break up large page mappings for this.
Right. Same for PCI device assignment. Breaking up large page mappings
should be a fairly normal operation.
Sure, just pointing out that this isn't free.
--
error compiling
On 12/14/2009 11:07 PM, Daniel Bareiro wrote:
Ah! I see you upload it today :-)
After a ./configure, I'm obtaining the following error when doing make:
r...@ubuntu:~/qemu-kvm-0.12.0-rc2# make
GEN config-host.h
CCqemu-nbd.o
CCqemu-tool.o
CCcutils.o
CC
On 12/13/2009 07:16 PM, Thomas Fjellstrom wrote:
Linux usually keeps very little RAM free (it's kept as cache). So there
has to be some action on the part of the host to get the guest to free
things. For Windows guests you can use ksm to reclaim free memory
(since Windows will zero it).
On 12/14/2009 05:50 PM, rek2 wrote:
VIRT includes a lot of shared memory, so it's not a very useful
number to
look at when trying to gauge how much memory a process is using.
Ok, so then what stats should we look to calculate the amount of
memory a server should have depending on how many
On 12/14/2009 09:37 PM, Marcelo Tosatti wrote:
The vcpus are initialized with irr_pending set to false, but
loading the LAPIC registers with pending IRR fails to reset
the irr_pending variable.
Thanks, applied and queued for .32 and .33.
--
error compiling committee.c: too many arguments
On 12/14/2009 10:36 PM, Marcelo Tosatti wrote:
So that the vcpu state is initialized, from vcpu thread context, after
machine initialization is settled.
This allows to revert apic_init's apic_reset call. apic_reset now
happens through system_reset, similarly to qemu upstream.
Applied,
On 12/15/2009 11:51 AM, Bernhard Held wrote:
Fix compile without eventfd.
Thanks, but already applied an identical patch from Christ Wright.
--
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
On 12/13/2009 01:58 PM, Ozan Çağlayan wrote:
KVM related messages on the host server:
~ # dmesg |grep kvm
[ 3649.058945] loaded kvm module (kvm-kmod-2.6.32)
[ 3683.736737] kvm: emulating exchange as write (It's interesting, what does it
mean?)
An exchange instruction (cmpxchg, likely)
On 12/08/2009 05:35 PM, Alexander Graf wrote:
We now have S390x KVM support in qemu upstream.
Unfortunately it doesn't work in qemu-kvm, because that has its own main
loop and slightly different calling conventions for the KVM helpers.
So let's hack in some small compat ifdefs that make
On 12/07/2009 12:47 PM, Avi Kivity wrote:
When ept is enabled, we aren't particularly interested in cr4.pge, so allow
the guest to own it. This improves performance in vmap() intensive loads.
This is now applied, after modifying according to review comments.
--
error compiling
Hi all,
I just triggered a nasty indefinite recursion in pci_default_read_config:
uint32_t pci_default_read_config(PCIDevice *d,
uint32_t address, int len)
{
uint32_t val = 0;
assert(len == 1 || len == 2 || len == 4);
if (pci_access_cap_config(d,
On 12/15/2009 12:57 PM, Hannes Reinecke wrote:
Hi all,
I just triggered a nasty indefinite recursion in pci_default_read_config:
uint32_t pci_default_read_config(PCIDevice *d,
uint32_t address, int len)
{
uint32_t val = 0;
assert(len == 1 || len == 2
On Mon, Dec 14, 2009 at 03:22:22PM -0800, Shirley Ma wrote:
Hello Michael,
On Mon, 2009-12-14 at 22:22 +0200, Michael S. Tsirkin wrote:
I dont insist, but my idea was
for (;;) {
b = vq-destroy(vq);
if (!b)
break;
--vi-num;
Avi Kivity wrote:
On 12/08/2009 05:35 PM, Alexander Graf wrote:
We now have S390x KVM support in qemu upstream.
Unfortunately it doesn't work in qemu-kvm, because that has its own main
loop and slightly different calling conventions for the KVM helpers.
So let's hack in some small compat
On Tue, Dec 15, 2009 at 12:59:41PM +0200, Avi Kivity wrote:
On 12/15/2009 12:57 PM, Hannes Reinecke wrote:
Hi all,
I just triggered a nasty indefinite recursion in pci_default_read_config:
uint32_t pci_default_read_config(PCIDevice *d,
uint32_t address, int
On Mon, Dec 14, 2009 at 06:36:37PM -0200, Marcelo Tosatti wrote:
So that the vcpu state is initialized, from vcpu thread context, after
machine initialization is settled.
This allows to revert apic_init's apic_reset call. apic_reset now
happens through system_reset, similarly to qemu
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 12:59:41PM +0200, Avi Kivity wrote:
On 12/15/2009 12:57 PM, Hannes Reinecke wrote:
Hi all,
I just triggered a nasty indefinite recursion in pci_default_read_config:
uint32_t pci_default_read_config(PCIDevice *d,
On Mon, Dec 14, 2009 at 02:08:38PM -0800, Shirley Ma wrote:
On Sun, 2009-12-13 at 13:43 +0200, Michael S. Tsirkin wrote:
Interesting. I think skb_goodcopy will sometimes
set *page to NULL. Will the above crash then?
Nope, when *page is NULL, *len is 0.
Hmm. Yes, I see, it is here:
+
On Tue, Dec 15, 2009 at 12:26:15PM +0100, Hannes Reinecke wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 12:59:41PM +0200, Avi Kivity wrote:
On 12/15/2009 12:57 PM, Hannes Reinecke wrote:
Hi all,
I just triggered a nasty indefinite recursion in pci_default_read_config:
On 12/15/2009 01:35 PM, Michael S. Tsirkin wrote:
Should just be static in fact. Here's a better one:
Changelog and signoff please.
--
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
On Tue, Dec 15, 2009 at 01:20:38PM +0200, Gleb Natapov wrote:
On Mon, Dec 14, 2009 at 06:36:37PM -0200, Marcelo Tosatti wrote:
So that the vcpu state is initialized, from vcpu thread context, after
machine initialization is settled.
This allows to revert apic_init's apic_reset call.
On 12/15/2009 01:13 PM, Alexander Graf wrote:
This should be CONFIG_PCI or CONFIG_PCI_MSI. Also, better to hack it
at the Makefile level.
That's what I did at first in a hacky way. To be honest, the new
makefile structure scares me a bit, so I'm not sure I'll easily figure
out how to
On 12/15/2009 02:24 PM, Marcelo Tosatti wrote:
This patch essentially revers commit 898c51c3. This commit fixes two
races. First race is like this:
vcpu0vcpu1
starts running
loads lapic state into kernel
sends event to vcpu1
On Tue, Dec 15, 2009 at 10:24:15AM -0200, Marcelo Tosatti wrote:
On Tue, Dec 15, 2009 at 01:20:38PM +0200, Gleb Natapov wrote:
On Mon, Dec 14, 2009 at 06:36:37PM -0200, Marcelo Tosatti wrote:
So that the vcpu state is initialized, from vcpu thread context, after
machine
On Tue, Dec 15, 2009 at 02:31:16PM +0200, Avi Kivity wrote:
On 12/15/2009 02:24 PM, Marcelo Tosatti wrote:
This patch essentially revers commit 898c51c3. This commit fixes two
races. First race is like this:
vcpu0vcpu1
starts running
loads lapic
Make config reads for assigned devices work
like they used to: both pci_default_read_config
and pci_default_cap_read_config call to pci_read_config,
which does the actual work.
This fixes infinite recursion introduced by
recent merge from stable-0.12.
Signed-off-by: Michael S. Tsirkin
Avi Kivity wrote:
On 12/15/2009 01:13 PM, Alexander Graf wrote:
This should be CONFIG_PCI or CONFIG_PCI_MSI. Also, better to hack it
at the Makefile level.
That's what I did at first in a hacky way. To be honest, the new
makefile structure scares me a bit, so I'm not sure I'll easily
On 12/15/2009 03:03 PM, Alexander Graf wrote:
Why isn't cpu_synchronize_state() suitable?
Because the KVM fd's are not available yet.
Then kvm_arch_load_regs() will fail as well, no?
Eeeh - there was a reason this didn't fail :-). I don't remember.
Please
On Mon, Dec 14, 2009 at 11:36:35PM -0300, Daniel Bareiro wrote:
Hi all!
I'm testing qemu-kvm-0.12.0-rc2 with the patch for compatfd of Chris
Wright on a host with Linux 2.6.32 from kernel.org and a virtual machine
with OpenBSD 4.5.
After to boot this virtual machine I'm observing by
Zachary Amsden zams...@redhat.com writes:
Damn, this is complicated crap. The analagous task in real life would
be keeping a band of howler monkeys, each in their own tree, singing in
unison while the lead vocalist jumps from tree to tree, and meanwhile,
an unseen conductor keeps changing
On Tue, Dec 15, 2009 at 11:10:54AM +0200, Avi Kivity wrote:
Well, binaries are shipped, but I guess you'd like to build from source.
We have several options:
- do nothing
- ship a generated SOURCES file which contains git URLs and commit
hashes, rely on the interested user to fetch and
Avi Kivity wrote:
On 12/14/2009 11:58 PM, Dustin Kirkland wrote:
I'm working on the packaging updates for Ubuntu Lucid, and I'm having
trouble with the BIOS bits of qemu-kvm.
It seems that a fair amount of the BIOS submodules are missing.
The roms/ tree is basically empty.
Well,
Ingmar Schraub wrote:
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed
two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it
(tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't
work. DHCP
2.) If you specify an USB device at the command line like -usbdevice
host:0421:00ab and the device is not available (not plugged-in) when you
start the guest, qemu segfaults.
Haven't heard this one yet. I'm assuming it's a qdev interaction.
No. It is monitor_printf(NULL, ...
Patch adding
On 12/08/2009 11:17 PM, Jan Kiszka wrote:
I don't see the need for setting any state in kvm_vcpu_events
automatically, on kernel entry (apparently there was consensus that
saving similar state explicitly in qemu was the way to go).
(I don't think so. IMHO the cleaner way is to avoid
On 12/06/2009 07:12 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 12/06/2009 06:55 PM, Jan Kiszka wrote:
User space may not want to overwrite asynchronously changing VCPU event
states on write-back. So allow to skip nmi.pending and sipi_vector by
setting corresponding bits in the flags
Michael S. Tsirkin wrote:
On Fri, Dec 11, 2009 at 12:06:26AM +0100, Alexander Graf wrote:
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
On Tue, Dec 15, 2009 at 04:18:00PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Fri, Dec 11, 2009 at 12:06:26AM +0100, Alexander Graf wrote:
When using -pcidevice on a device that is already in use by a kernel driver
all the user gets is the following (very useful)
On Tue, 2009-12-15 at 11:10 +0200, Avi Kivity wrote:
Well, binaries are shipped, but I guess you'd like to build from source.
Right, sorry I was ambiguous.
We have several options:
...
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Raindog
Sent: Tuesday, December 15, 2009 2:25 AM
To: kvm@vger.kernel.org
Subject: debugging windows guests
Hello,
I am researching KVM as a malware analysis platform and had
Sorry, forgot to CC all.
Thanks
Shirley
---BeginMessage---
On Tue, Dec 15, 2009 at 07:59:42AM -0800, Shirley Ma wrote:
Hello Michael,
On Tue, 2009-12-15 at 12:57 +0200, Michael S. Tsirkin wrote:
No, this code would be in virtio net.
destroy would simply be the virtqueue API that returns
On Tue, 2009-12-15 at 13:33 +0200, Michael S. Tsirkin wrote:
So what I would suggest is, have function
that just copies part of skb, and have
caller open-code allocating the skb and free up
pages as necessary.
Yes, the updated patch has changed the function.
What I am asking is why do we add
On Tue, Dec 15, 2009 at 08:25:20AM -0800, Shirley Ma wrote:
On Tue, 2009-12-15 at 13:33 +0200, Michael S. Tsirkin wrote:
So what I would suggest is, have function
that just copies part of skb, and have
caller open-code allocating the skb and free up
pages as necessary.
Yes, the updated
Avi Kivity wrote:
On 12/06/2009 07:12 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 12/06/2009 06:55 PM, Jan Kiszka wrote:
User space may not want to overwrite asynchronously changing VCPU event
states on write-back. So allow to skip nmi.pending and sipi_vector by
setting
Avi Kivity wrote:
On 12/08/2009 11:17 PM, Jan Kiszka wrote:
I don't see the need for setting any state in kvm_vcpu_events
automatically, on kernel entry (apparently there was consensus that
saving similar state explicitly in qemu was the way to go).
(I don't think so. IMHO the cleaner
On 12/15/2009 06:41 PM, Jan Kiszka wrote:
OK, but calling these bits SET makes no sense anymore. What about
KVM_VCPUEVENT_VALID_*?
Sure. Want to patch?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
On 12/15/2009 06:43 PM, Jan Kiszka wrote:
I now agree. But instead of SCOPE_RESET and SCOPE_RUNTIME (or whatever
that was), how about SCOPE_GPR, SCOPE_FPU, SCOPE_SREGS etc. That means
the backing code in kvm.c doesn't have to know what qemu is interested
in wrt SCOPE_RESET, and it's easier
Avi Kivity wrote:
On 12/15/2009 06:43 PM, Jan Kiszka wrote:
I now agree. But instead of SCOPE_RESET and SCOPE_RUNTIME (or whatever
that was), how about SCOPE_GPR, SCOPE_FPU, SCOPE_SREGS etc. That means
the backing code in kvm.c doesn't have to know what qemu is interested
in wrt
With qemu-kvm.git from this morning (about an hour ago), I see the following
message. Qemu continues to run after this, but the guest is unresponsive and
the qemu process is chewing up 100% cpu.
rom: out of memory (rom pxe-virtio.bin, addr 0x000de800, size 0xdc00,
max
Michael S. Tsirkin wrote:
On Fri, Dec 11, 2009 at 12:06:25AM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
Region 0: Memory at d210 (64-bit, non-prefetchable)
On Tue, 15 Dec 2009 15:41:33 +0100
Gerd Hoffmann kra...@redhat.com wrote:
2.) If you specify an USB device at the command line like -usbdevice
host:0421:00ab and the device is not available (not plugged-in) when you
start the guest, qemu segfaults.
Haven't heard this one yet. I'm
On Tue, Dec 15, 2009 at 07:16:13PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Fri, Dec 11, 2009 at 12:06:25AM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
Michael S. Tsirkin wrote:
I guess this means you'll have to find a device with a sub-page BAR
to test this on, instead of hacking driver for a device with full
page BAR. Did anyone ever try doing passthrough on an emulated
device in nested virt?
We don't emulate an IOMMU, so no.
Alex
--
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 use.
Alexander Graf (3):
Enable non page
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
Region 0: Memory at d210 (64-bit, non-prefetchable) [size=4K]
Region 2: Memory at d2101000 (64-bit, non-prefetchable) [size=256]
Region
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 initializing device pci-assign
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 ag...@suse.de
---
hw/device-assignment.c |
On Tue, Dec 15, 2009 at 07:30:26PM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
Region 0: Memory at d210 (64-bit, non-prefetchable) [size=4K]
Region 2:
I submit one split patch for review to make sure that's the right format.
I copied Rusty's comment for the commit message, and change destroy
to detach since we destroy the buffers in caller. This patch is built
against Dave's net-next tree.
There's currently no way for a virtio driver to ask for
On Tue, Dec 15, 2009 at 07:30:28PM +0100, Alexander Graf wrote:
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
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:26PM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
Region 0: Memory at d210 (64-bit, non-prefetchable)
On Tue, Dec 15, 2009 at 07:47:35PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:26PM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it through because it has a BAR of 256 bytes:
On Tue, Dec 15, 2009 at 10:42:53AM -0800, Shirley Ma wrote:
I submit one split patch for review to make sure that's the right format.
I copied Rusty's comment for the commit message, and change destroy
to detach since we destroy the buffers in caller. This patch is built
against Dave's
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:27PM +0100, Alexander Graf wrote:
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
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:47:35PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:26PM +0100, Alexander Graf wrote:
While trying to get device passthrough working with an emulex hba, kvm
refused to pass it
On Fri, Dec 11, 2009 at 2:34 PM, Jiri Zupka jzu...@redhat.com wrote:
Hello,
we write KSM_overcommit test. If we calculate memory for guest we need to
know
which architecture is Guest. If it is a 32b or 32b with PAE or 64b system.
Because with a 32b guest we can allocate only 3100M +-.
Thanks Michael, will fix them all.
Shirley
--
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
Hello Michael,
On Tue, 2009-12-15 at 20:47 +0200, Michael S. Tsirkin wrote:
+ detach_buf(vq, i);
+ END_USE(vq);
+ return vq-data[i];
In fact, this will return NULL always, won't it?
Nope, I changed the destroy to detach and
* Alexander Graf (ag...@suse.de) wrote:
@@ -405,7 +511,7 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
} else {
pci_dev-v_addrs[i].u.r_virtbase =
mmap(NULL,
- (cur_region-size + 0xFFF)
* Michael S. Tsirkin (m...@redhat.com) wrote:
On Tue, Dec 15, 2009 at 07:30:27PM +0100, Alexander Graf wrote:
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.
* Alexander Graf (ag...@suse.de) wrote:
+static void assign_failed_examine(AssignedDevice *dev)
+{
+char name[PATH_MAX], dir[PATH_MAX], driver[PATH_MAX] = {}, *ns;
+uint16_t vendor_id, device_id;
+int r;
+
+/* XXX implement multidomain */
+sprintf(dir,
On Tue, Dec 15, 2009 at 08:04:10PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:47:35PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:26PM +0100, Alexander Graf wrote:
While trying to get
On Tue, Dec 15, 2009 at 07:54:41PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:27PM +0100, Alexander Graf wrote:
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
Chris Wright wrote:
* Alexander Graf (ag...@suse.de) wrote:
+static void assign_failed_examine(AssignedDevice *dev)
+{
+char name[PATH_MAX], dir[PATH_MAX], driver[PATH_MAX] = {}, *ns;
+uint16_t vendor_id, device_id;
+int r;
+
+/* XXX implement multidomain */
+
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 08:04:10PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:47:35PM +0100, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 07:30:26PM +0100,
On Tue, Dec 15, 2009 at 12:28:52PM -0800, Chris Wright wrote:
* Alexander Graf (ag...@suse.de) wrote:
+static void assign_failed_examine(AssignedDevice *dev)
+{
+char name[PATH_MAX], dir[PATH_MAX], driver[PATH_MAX] = {}, *ns;
+uint16_t vendor_id, device_id;
+int r;
+
+
On Tue, Dec 15, 2009 at 11:50:23AM -0800, Chris Wright wrote:
* Alexander Graf (ag...@suse.de) wrote:
@@ -405,7 +511,7 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
} else {
pci_dev-v_addrs[i].u.r_virtbase =
On Tue, Dec 15, 2009 at 11:14:07AM -0800, Shirley Ma wrote:
Hello Michael,
On Tue, 2009-12-15 at 20:47 +0200, Michael S. Tsirkin wrote:
+ detach_buf(vq, i);
+ END_USE(vq);
+ return vq-data[i];
In fact, this will return
On 12/15/2009 08:21 AM, Marcelo Tosatti wrote:
On Mon, Dec 14, 2009 at 06:08:42PM -1000, Zachary Amsden wrote:
snip
+ atomic_set(per_cpu(cpu_tsc_synchronized, freq-cpu),
0);
+ spin_lock(kvm_lock);
+ list_for_each_entry(kvm,vm_list, vm_list) {
+
Forwarding to list as I replied to only Yan =(
Original Message
Subject:Re: debugging/instrumenting windows guests + some bugs
Date: Tue, 15 Dec 2009 11:55:15 -0800
From: Raindog rain...@macrohmasheen.com
To: Yan Vugenfirer yvuge...@redhat.com
On 12/15/2009
On Wed, Dec 16, 2009 at 09:06:12AM +1030, Rusty Russell wrote:
On Tue, 15 Dec 2009 06:52:53 am Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 12:08:05PM -0800, Shirley Ma wrote:
Hello Michael,
I agree with the comments (will have two patches instead of 4 based on
Rusty's
Howdy all,
I am attempting to evaluate a few different virtualization platforms. I've
been going about this by installing a really basic XP host, and running some
benchmarks. I realize these are synthetic benchmarks, but it at least allows
me to see how the virtualization platforms differ.
Avi Kivity wrote:
On 12/15/2009 06:41 PM, Jan Kiszka wrote:
OK, but calling these bits SET makes no sense anymore. What about
KVM_VCPUEVENT_VALID_*?
Sure. Want to patch?
Here we go:
-
KVM: x86: Adjust KVM_VCPUEVENT flag names
They are also used on KVM_GET_VCPU_EVENTS, so
* Alexander Graf (ag...@suse.de) wrote:
Chris Wright wrote:
* Alexander Graf (ag...@suse.de) wrote:
+static void assign_failed_examine(AssignedDevice *dev)
+{
+char name[PATH_MAX], dir[PATH_MAX], driver[PATH_MAX] = {}, *ns;
+uint16_t vendor_id, device_id;
+int r;
+
1 - 100 of 117 matches
Mail list logo
