Gregory Haskins wrote:
> Certain GSI's support lockless injecton, but we have no way to detect
> which ones at the GSI level. Knowledge of this attribute will be
> useful later in the series so that we can optimize irqfd injection
> paths for cases where we know the code will not sleep. Therefore
IRQFD currently uses a deferred workqueue item to execute the injection
operation. It was originally designed this way because kvm_set_irq()
required the caller to hold the irq_lock mutex, and the eventfd callback
is invoked from within a non-preemptible critical section.
With the advent of lockl
(Applies to kvm.git/master:11b06403)
The following patches are cleanups/enhancements for IRQFD now that
we have lockless interrupt injection. For more details, please see
the patch headers.
These patches pass checkpatch, and are fully tested. Please consider
for merging. They are an enhancemen
Certain GSI's support lockless injecton, but we have no way to detect
which ones at the GSI level. Knowledge of this attribute will be
useful later in the series so that we can optimize irqfd injection
paths for cases where we know the code will not sleep. Therefore,
we provide an API to query a
On Wed, 2009-10-21 at 17:03 +0200, Alexander Graf wrote:
> KVM for PowerPC only supports embedded cores at the moment.
>
> While it makes sense to virtualize on small machines, it's even more fun
> to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
>
> This patchset implements
As in other tests, we should append the qemu extra
options instead of replacing them.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm_tests.cfg.sample |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/client/tests/kvm/kvm_tests.cfg.sample
b/client/te
Am 22.10.2009 um 18:28 schrieb Anthony Liguori :
Avi Kivity wrote:
On 10/21/2009 07:13 AM, MORITA Kazutaka wrote:
Hi everyone,
Sheepdog is a distributed storage system for KVM/QEMU. It provides
highly available block level storage volumes to VMs like Amazon EBS.
Sheepdog supports advanced vo
Am 22.10.2009 um 18:29 schrieb Avi Kivity :
On 10/13/2009 08:35 AM, Jan Kiszka wrote:
It can be particularly slow if you use in-kernel irqchips and the
default NIC emulation (up to 10 times slower), some effect I always
wanted to understand on a rainy day. So, when you actually want -net
user,
On Wed, Oct 21, 2009 at 04:08:29PM +0200, Alexander Graf wrote:
> From: Arnd Bergmann
>
> With big endian userspace, we can't quite figure out if a pointer
> is 32 bit (shifted >> 32) or 64 bit when we read a 64 bit pointer.
>
> This is what happens with dirty logging. To get the pointer interpr
On Thu, Oct 22, 2009 at 02:00:15PM +0200, Michael S. Tsirkin wrote:
> Hi!
> I'm sometimes getting segfaults when I kill qemu.
> This time I caught it when qemu was under gdb:
>
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x411d0940 (LWP 14446)]
> 0x0040
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Wolfgang Mauerer
> Sent: Mittwoch, 21. Oktober 2009 16:21
> To: Dietmar Maurer
> Cc: kvm@vger.kernel.org; Kiszka, Jan
> Subject: Re: [PATCH 2/2] kvm-kmod: Document the build process
>
This looks very interesting - how does this compare with Exanodes/Seanodes?
Thanks,
Avishay
--
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
On Thu, 2009-10-22 at 10:56 -0700, Shirley Ma wrote:
> On Thu, 2009-10-22 at 19:47 +0200, Michael S. Tsirkin wrote:
> > What happens if you reset my tree to commit
> > 47e465f031fc43c53ea8f08fa55cc3482c6435c8?
>
> I am going to clean up my upperstream git tree and retest first. Then
> I
> will try
On Thu, 2009-10-22 at 19:43 +0200, Michael S. Tsirkin wrote:
>
> Possibly we'll have to debug this in vhost in host kernel.
> I would debug this directly, it's just that my setup is somehow
> different and I do not see this issue, otherwise I would not
> waste your time.
>
> Can we add some prin
On Thu, 2009-10-22 at 19:47 +0200, Michael S. Tsirkin wrote:
> What happens if you reset my tree to commit
> 47e465f031fc43c53ea8f08fa55cc3482c6435c8?
I am going to clean up my upperstream git tree and retest first. Then I
will try back up this commit.
> Looks like there are 2 issues:
> - upstrea
On Thu, Oct 22, 2009 at 10:44:29AM -0700, Shirley Ma wrote:
> On Thu, 2009-10-22 at 19:36 +0200, Michael S. Tsirkin wrote:
> > Upstream is Avi's qemu-kvm.git?
> > So, for a moment taking vhost out of the equation, it seems that MSI
> > was
> > broken in Avi's tree again, after I forked my tree?
>
On Thu, Oct 22, 2009 at 10:23:44AM -0700, Shirley Ma wrote:
> On Thu, 2009-10-22 at 15:13 +0200, Michael S. Tsirkin wrote:
> > OK, I sent a patch that should fix the errors for you.
> > Could you please confirm, preferably on-list, whether
> > the patch makes the errors go away for you with
> > use
On Thu, 2009-10-22 at 19:36 +0200, Michael S. Tsirkin wrote:
> Upstream is Avi's qemu-kvm.git?
> So, for a moment taking vhost out of the equation, it seems that MSI
> was
> broken in Avi's tree again, after I forked my tree?
The upper stream qemu git tree never worked for me w/i MSI, the boot
hun
On Thu, Oct 22, 2009 at 10:32:55AM -0700, Shirley Ma wrote:
> On Thu, 2009-10-22 at 10:23 -0700, Shirley Ma wrote:
> > Yes, agreed. One observation is when I enable PCI MSI in guest kernel,
> > I
> > found that even without vhost supportin host kernel the network
> > doesn't
> > work either. So I t
On Thu, 2009-10-22 at 10:23 -0700, Shirley Ma wrote:
> Yes, agreed. One observation is when I enable PCI MSI in guest kernel,
> I
> found that even without vhost supportin host kernel the network
> doesn't
> work either. So I think this is nothing related to vhost. I need to
> find
> why PCI MSI do
On Thu, 2009-10-22 at 15:13 +0200, Michael S. Tsirkin wrote:
> OK, I sent a patch that should fix the errors for you.
> Could you please confirm, preferably on-list, whether
> the patch makes the errors go away for you with
> userspace virtio?
Confirmed, your patch has fixed irq handler mismatch e
On Tue, Oct 20, 2009 at 07:15:09PM +0200, Michael S. Tsirkin wrote:
> KVM does not virtualize low address bits for memory accesses, so we must
> require that PCI BAR size is a multiple of 4K for passthrough to work
> (this also guarantees that address is 4K aligned).
>
> Users of recent linux kern
On 10/22/2009 06:25 PM, Wolfgang Mauerer wrote:
consider that you clone kvm-kmod from your repo and
then create local clones from which you do the build. If you don't
happen to have /path/to/my/kvm-kmod/../kvm, then the relative
submodule URL won't work, but the absolute one will.
On 10/13/2009 08:35 AM, Jan Kiszka wrote:
It can be particularly slow if you use in-kernel irqchips and the
default NIC emulation (up to 10 times slower), some effect I always
wanted to understand on a rainy day. So, when you actually want -net
user, try -no-kvm-irqchip.
This might be due t
Avi Kivity wrote:
On 10/21/2009 07:13 AM, MORITA Kazutaka wrote:
Hi everyone,
Sheepdog is a distributed storage system for KVM/QEMU. It provides
highly available block level storage volumes to VMs like Amazon EBS.
Sheepdog supports advanced volume management features such as snapshot,
cloning,
On 10/15/2009 04:58 PM, Glauber Costa wrote:
The motivation for relative adjustment is when you have a jitter
resistant place to gather timing information (like the kernel, which can
disable interrupts and preemption), then pass it on to kvm without
losing information due to scheduling. For mi
Avi Kivity wrote:
> On 10/22/2009 06:13 PM, Wolfgang Mauerer wrote:
>> Hi,
>>
>> Avi Kivity wrote:
>>
>>> On 10/20/2009 02:11 PM, wolfgang.maue...@siemens.com wrote:
>>>
From: Wolfgang Mauerer
Most people won't have the sources installed in the path
that is the current
On Tue, Oct 20, 2009 at 04:39:04PM -0200, Glauber Costa wrote:
> [v2: we already return -errno, so fix testers ]
> [v3: keep error message for apic related failures ]
> [v4: fix silly compile mistake ]
>
> Signed-off-by: Glauber Costa
Applied, thanks (please mind the indentation).
--
To unsubsc
On 10/22/2009 06:13 PM, Wolfgang Mauerer wrote:
Hi,
Avi Kivity wrote:
On 10/20/2009 02:11 PM, wolfgang.maue...@siemens.com wrote:
From: Wolfgang Mauerer
Most people won't have the sources installed in the path
that is the current default setting.
--- a/.gitmodules
+++ b/.gitmodules
Hi,
Avi Kivity wrote:
> On 10/20/2009 02:11 PM, wolfgang.maue...@siemens.com wrote:
>> From: Wolfgang Mauerer
>>
>> Most people won't have the sources installed in the path
>> that is the current default setting.
>>
>> --- a/.gitmodules
>> +++ b/.gitmodules
>> @@ -1,3 +1,3 @@
>> [submodule "linu
Some distributors ship CD and DVD files with SHA1 hash sums instead
of MD5 hash sums, so let's extend the kvm_utils functions to
evaluate and compare SHA1 hashes:
* hash_file(): Calculate a hash sum for a file, supports SHA1 check as well,
replaces md5sum_file()
* unmap_url_cache(): Reimplementati
Gleb Natapov wrote on 22/10/2009 11:04:58:
> From:
>
> Gleb Natapov
>
> To:
>
> Orit Wasserman/Haifa/i...@ibmil
>
> Cc:
>
> Abel Gordon/Haifa/i...@ibmil, aligu...@us.ibm.com, Ben-Ami Yassour1/
> Haifa/i...@ibmil, kvm@vger.kernel.org, md...@us.ibm.com, Muli Ben-
> Yehuda/Haifa/i...@ibmil
>
> Da
Hi list,
(CC: Ingo and Avi)
CPU time of a guest is always accounted in 'user' time
without concern for the nice value of its counterpart
process although the guest is scheduled under the nice
value.
This patch fixes the defect and accounts cpu time of
a niced guest in 'nice' time as same as a nic
Avi Kivity wrote:
> On 10/22/2009 05:14 PM, Gregory Haskins wrote:
>> Yeah, I was thinking about that after I initially responded to Gleb.
>>
>> I am thinking something along these lines:
>>
>> Provide a function that lets you query a GSI for whether it supports
>> LOCKLESS or not. Then we can eit
On 10/21/2009 07:13 AM, MORITA Kazutaka wrote:
Hi everyone,
Sheepdog is a distributed storage system for KVM/QEMU. It provides
highly available block level storage volumes to VMs like Amazon EBS.
Sheepdog supports advanced volume management features such as snapshot,
cloning, and thin provisioni
On 10/22/2009 05:14 PM, Gregory Haskins wrote:
Yeah, I was thinking about that after I initially responded to Gleb.
I am thinking something along these lines:
Provide a function that lets you query a GSI for whether it supports
LOCKLESS or not. Then we can either do one of two things:
1) Chec
On 10/20/2009 02:11 PM, wolfgang.maue...@siemens.com wrote:
From: Wolfgang Mauerer
Most people won't have the sources installed in the path
that is the current default setting.
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,3 @@
[submodule "linux-2.6"]
path = linux-2.6
- url = .
Avi Kivity wrote:
> On 10/21/2009 05:42 PM, Gregory Haskins wrote:
>> I believe Avi, Michael, et. al. were in agreement with me on that design
>> choice. I believe the reason is that there is no good way to do EOI/ACK
>> feedback within the constraints of an eventfd pipe which would be
>> required
On 10/21/2009 03:18 AM, Max Laier wrote:
On Friday 02 October 2009 00:16:58 you wrote:
It is possible that stale EPTP-tagged mappings are used, if a
vcpu migrates to a different pcpu.
Set KVM_REQ_TLB_FLUSH in vmx_vcpu_load, when switching pcpus, which
will invalidate both VPID and EPT mappi
On 10/21/2009 05:42 PM, Gregory Haskins wrote:
I believe Avi, Michael, et. al. were in agreement with me on that design
choice. I believe the reason is that there is no good way to do EOI/ACK
feedback within the constraints of an eventfd pipe which would be
required for the legacy pin-type inter
On Wednesday 21 October 2009, Alexander Graf wrote:
>
> KVM for PowerPC only supports embedded cores at the moment.
>
> While it makes sense to virtualize on small machines, it's even more fun
> to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
>
> This patchset implements K
On 10/21/2009 10:29 PM, Daniel Schwager wrote:
opreport -l --symbols | less
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples %image name app name
symbol name
418814 98.5250 no-vmlinux no-vmlinux
On Thu, Oct 22, 2009 at 02:34:56PM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 21, 2009 at 04:59:20PM -0700, Shirley Ma wrote:
> >
> > Hello Michael,
> >
> > >There was a recent bugfix in qemu-kvm I pushed.
> > >Could you please verify that you have
> > cec75e39151e49cc90c849eab5d0d729667c9e68
Avi Kivity wrote on 20/10/2009 06:56:39:
> From:
>
> Avi Kivity
>
> To:
>
> Orit Wasserman/Haifa/i...@ibmil
>
> Cc:
>
> kvm@vger.kernel.org, Ben-Ami Yassour1/Haifa/i...@ibmil, Abel Gordon/
> Haifa/i...@ibmil, Muli Ben-Yehuda/Haifa/i...@ibmil,
> aligu...@us.ibm.com, md...@us.ibm.com
>
> Date:
>
Error was:
monitor.c: In function 'print_cpu_iter':
monitor.c:450: error: format '%ld' expects type 'long int', but argument 3 has
type 'int64_t'
Signed-off-by: Pierre Riteau
---
monitor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index b4c4
Avi Kivity wrote on 20/10/2009 06:44:41:
> From:
>
> Avi Kivity
>
> To:
>
> Orit Wasserman/Haifa/i...@ibmil
>
> Cc:
>
> kvm@vger.kernel.org, Ben-Ami Yassour1/Haifa/i...@ibmil, Abel Gordon/
> Haifa/i...@ibmil, Muli Ben-Yehuda/Haifa/i...@ibmil,
> aligu...@us.ibm.com, md...@us.ibm.com
>
> Date:
>
Avi Kivity wrote on 20/10/2009 06:24:33:
> From:
>
> Avi Kivity
>
> To:
>
> Orit Wasserman/Haifa/i...@ibmil
>
> Cc:
>
> kvm@vger.kernel.org, Ben-Ami Yassour1/Haifa/i...@ibmil, Abel Gordon/
> Haifa/i...@ibmil, Muli Ben-Yehuda/Haifa/i...@ibmil,
> aligu...@us.ibm.com, md...@us.ibm.com
>
> Date:
>
Avi Kivity wrote on 20/10/2009 06:00:50:
> From:
>
> Avi Kivity
>
> To:
>
> Orit Wasserman/Haifa/i...@ibmil
>
> Cc:
>
> kvm@vger.kernel.org, Ben-Ami Yassour1/Haifa/i...@ibmil, Abel Gordon/
> Haifa/i...@ibmil, Muli Ben-Yehuda/Haifa/i...@ibmil,
> aligu...@us.ibm.com, md...@us.ibm.com
>
> Date:
>
On Wed, Oct 21, 2009 at 04:59:20PM -0700, Shirley Ma wrote:
>
> Hello Michael,
>
> >There was a recent bugfix in qemu-kvm I pushed.
> >Could you please verify that you have
> cec75e39151e49cc90c849eab5d0d729667c9e68 ?
>
> Yes, I cloned your qemu-kvm and kernel git.
It seems that the errors you
From: Arnd Bergmann
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted >> 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer interpreted
correctly, we thus need Arnd's patch to implement a compat layer for
th
On Thu, Oct 22, 2009 at 6:47 PM, Avi Kivity wrote:
> On 10/20/2009 05:00 PM, Ryota Ozaki wrote:
>>
>> Hi Avi,
>>
>> This is the patch we discussed earlier. Please review it.
>>
>>
>
> It looks good to me.
>
>> BTW, should this be sent to lkml as well?
>>
>>
>
>
> In fact, it should go through tip.
Hi!
I'm sometimes getting segfaults when I kill qemu.
This time I caught it when qemu was under gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x411d0940 (LWP 14446)]
0x0040afb4 in qemu_mod_timer (ts=0x19f0fd0, expire_time=62275467335)
at /home/mst/scm/
Avi Kivity wrote:
So why not do it for this instruction as well? Instead of updating the
psw, return a success/error code and let the kernel update psw.
It's not a single instruction, but a set of reasons we need the psw in
userspace:
- for logging the instruction address on exits
- to check i
On Wed, Oct 21, 2009 at 04:59:20PM -0700, Shirley Ma wrote:
>
> Hello Michael,
>
> >There was a recent bugfix in qemu-kvm I pushed.
> >Could you please verify that you have
> cec75e39151e49cc90c849eab5d0d729667c9e68 ?
>
> Yes, I cloned your qemu-kvm and kernel git.
> > I am posting the errors fr
On 10/21/2009 11:31 PM, Lucas Meneghel Rodrigues wrote:
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -339,20 +339,27 @@ class VM:
+elif params.get("sha1sum"):
+logging.debug("Comparing expected SHA1 sum with SHA1 sum of "
+
On 10/21/2009 11:31 PM, Lucas Meneghel Rodrigues wrote:
Some distributors ship CD and DVD files with SHA1 hash sums instead
of MD5 hash sums, so let's extend the kvm_utils functions to
evaluate and compare SHA1 hashes:
* sha1sum_file(): Calculate SHA1 sum for file
+def sha1sum_file(filename, siz
On 10/21/2009 04:43 PM, Orit Wasserman wrote:
It is possible L1 called vmlaunch but we didn't actually run L2 (for
example there was an interrupt and
enable_irq_window switched back to L1 before running L2). L1 thinks the
vmlaunch was successful and call vmresume in the next time
but KVM needs t
On 10/22/2009 11:28 AM, Tomasz Chmielewski wrote:
To sum up the thread: I guess qemu _without_ KVM will only use one
CPU, even when you assign more CPUs to the guest?
Yes.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubs
On 10/22/2009 12:43 PM, Carsten Otte wrote:
Avi Kivity wrote:
On x86 we avoid emulating instructions in userspace. Instead the
kernel requests userspace to do something (triggered by the
instruction), and the kernel does anything which might be implied by
the instruction (like copying the res
Avi Kivity wrote:
On x86 we avoid emulating instructions in userspace. Instead the kernel
requests userspace to do something (triggered by the instruction), and
the kernel does anything which might be implied by the instruction (like
copying the result into a register, or updating pc).
An ex
Marcelo Tosatti wrote:
> On Tue, Oct 20, 2009 at 02:15:10PM +0200, Jan Kiszka wrote:
>> Fixes "cast to pointer from integer of different size" on 32-bit hosts
>> and applies a micro-refactoring.
>>
>> Signed-off-by: Jan Kiszka
>
> Applied, thanks.
Mmpf, sorry, please replace that patch (provided
On 10/22/2009 12:25 PM, Alexander Graf wrote:
If you send someone's patch, you need to sign this off. That says
you are legally allowed to send it along.
Ack means "I have a say in this area and it looks good to me", you
add it when someone else is doing the sending.
Ok, so is it still a F
On 10/22/2009 12:20 PM, Carsten Otte wrote:
Avi Kivity wrote:
gdb is hardly performance critical. Is that the only reason for the
change?
Right, gdb is not performance critical. gdb is the reason for moving
it out of the union, performance is the reason for having it in
kvm_run at all.
There'
On 10/22/2009 12:22 PM, Carsten Otte wrote:
Avi Kivity wrote:
Right, but why? x86 qemu doesn't care about either pc or eflags
(with in-kernel irqchip, which s390 essentially is).
For different reasons. Most prominent for setting the condition code,
which is a sideband result of most instructio
On 22.10.2009, at 12:23, Avi Kivity wrote:
On 10/21/2009 04:08 PM, Alexander Graf wrote:
From: Arnd Bergmann
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted>> 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get th
On 10/21/2009 04:08 PM, Alexander Graf wrote:
From: Arnd Bergmann
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted>> 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer interpreted
correctly, we thus need
Avi Kivity wrote:
Right, but why? x86 qemu doesn't care about either pc or eflags (with
in-kernel irqchip, which s390 essentially is).
For different reasons. Most prominent for setting the condition code,
which is a sideband result of most instructions that indicates whether or
not the instruct
Avi Kivity wrote:
gdb is hardly performance critical. Is that the only reason for the
change?
Right, gdb is not performance critical. gdb is the reason for moving it
out of the union, performance is the reason for having it in kvm_run at all.
There's only more reason to it: with a little tweaki
On 22.10.2009, at 12:03, Avi Kivity wrote:
On 10/22/2009 11:55 AM, Alexander Graf wrote:
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the
structure?
Best to put it after the union (and as a
On 10/22/2009 11:55 AM, Alexander Graf wrote:
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous l
On 10/22/2009 11:18 AM, Carsten Otte wrote:
I'd also appreciate an explanation of what this is all about.
The processor status word does contain various bits about the CPU's
state, such as interrupt mask bits, current address space, and the
current instruction address. The status is kept in t
On 22.10.2009, at 11:55, Alexander Graf wrote:
PSW = (eflags << 32) | pc;
Eh - 64 of course. The PSW is 128 bits.
Alex
--
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/major
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous location still works). If you're reading it
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous location still works). If you're reading it
from the kernel, also need a way to tell the ker
On 10/20/2009 05:00 PM, Ryota Ozaki wrote:
Hi Avi,
This is the patch we discussed earlier. Please review it.
It looks good to me.
BTW, should this be sent to lkml as well?
In fact, it should go through tip.git, not kvm.git, so please send to
lkml and copy Ingo.
Acked-by: Avi
Avi Kivity wrote:
Some 1-CPU guests have only one thread though?
Are you sure they're using kvm? Try 'info kvm' in the monitor. tcg
will only use on thread (more will be spawned for I/O, but will
eventually die).
Indeed, that was a good suggestion - they were not using KVM (support
not
On Wed, Oct 21, 2009 at 04:59:20PM -0700, Shirley Ma wrote:
> Hello Michael,
>
> >There was a recent bugfix in qemu-kvm I pushed.
> >Could you please verify that you have
> >cec75e39151e49cc90c849eab5d0d729667c9e68
> ?
>
> Yes, I cloned your qemu-kvm and kernel git. Here is "git log" output:
>
On Wed, Oct 21, 2009 at 11:42:47PM -0700, Chris Wright wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > KVM does not virtualize low address bits for memory accesses, so we must
> > require that PCI BAR size is a multiple of 4K for passthrough to work
> > (this also guarantees that address
Avi Kivity wrote:
@@ -116,6 +117,11 @@
__u64 cr8;
__u64 apic_base;
+#ifdef CONFIG_S390
+/* the processor status word for s390 */
+__u64 psw_mask; /* psw upper half */
+__u64 psw_addr; /* psw lower half */
+#endif
Doesn't this break backward compatibility by changing the str
On 22.10.2009, at 11:08, Avi Kivity wrote:
On 10/20/2009 06:40 PM, Carsten Otte wrote:
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
+#include
#include
#include
#include
Not needed.
@@ -116,6 +117,11 @@
__u
On 10/20/2009 06:40 PM, Carsten Otte wrote:
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
+#include
#include
#include
#include
Not needed.
@@ -116,6 +117,11 @@
__u64 cr8;
__u64 apic_base;
+#ifdef CONFIG_
On Wed, Oct 21, 2009 at 04:43:44PM +0200, Orit Wasserman wrote:
> > > @@ -4641,10 +4955,13 @@ static void vmx_complete_interrupts(struct
> > vcpu_vmx *vmx)
> > > int type;
> > > bool idtv_info_valid;
> > >
> > > - exit_intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
> > > -
> > > vmx->exi
On 10/22/2009 09:35 AM, Sheng Yang wrote:
On Tuesday 20 October 2009 20:37:20 Marcelo Tosatti wrote:
GUEST_CR3 is updated via kvm_set_cr3 whenever CR3 value
changes.
The description is not that accuracy... If CR3 value change in guest when EPT
enabled, no VM Exit would happen, then no
On Tuesday 20 October 2009 20:37:20 Marcelo Tosatti wrote:
> GUEST_CR3 is updated via kvm_set_cr3 whenever CR3 value
> changes.
The description is not that accuracy... If CR3 value change in guest when EPT
enabled, no VM Exit would happen, then no kvm_set_cr3...
--
regards
Yang, Sheng
>
> Sign
On 10/20/2009 04:59 PM, Marcelo Tosatti wrote:
Nice. Any reason why ept_load_pdptrs() couldn't go the same way?
Its already protected by VCPU_EXREG_PDPTR caching, so it does not buy
much.
The advantage would symmetry to cr3.
Yes, the PDPTRs fulfil exactly the same role as cr
On 10/20/2009 04:48 PM, Tomasz Chmielewski wrote:
Avi Kivity wrote:
On 10/20/2009 10:19 PM, Tomasz Chmielewski wrote:
I meant, how many qemu threads are there, and how much cpu does
each take?
There is only one qemu thread for the 4-cpu guest.
Not possible. Even a single-cpu guest has t
86 matches
Mail list logo
