On 04/24/2012 12:16 AM, Avi Kivity wrote:
Using RCU for lockless shadow walking can increase the amount of memory
in use by the system, since RCU grace periods are unpredictable. We also
have an unconditional write to a shared variable (reader_counter), which
isn't good for scaling.
On Mon, Apr 23, 2012 at 05:04:40PM +0300, Michael S. Tsirkin wrote:
The idea is simple: there's a bit, per APIC, in guest memory,
that tells the guest that it does not need EOI.
Guest tests it using a single est and clear operation - this is
necessary so that host can detect interrupt nesting
On Tue, Apr 24, 2012 at 09:50:02AM +0300, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 05:04:40PM +0300, Michael S. Tsirkin wrote:
The idea is simple: there's a bit, per APIC, in guest memory,
that tells the guest that it does not need EOI.
Guest tests it using a single est and clear
On Tue, Apr 24, 2012 at 09:58:35AM +0300, Michael S. Tsirkin wrote:
On Tue, Apr 24, 2012 at 09:50:02AM +0300, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 05:04:40PM +0300, Michael S. Tsirkin wrote:
The idea is simple: there's a bit, per APIC, in guest memory,
that tells the guest that it
On Mon, Apr 23, 2012 at 04:31:04PM +0300, Avi Kivity wrote:
On 04/22/2012 05:20 PM, Gleb Natapov wrote:
On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote:
On 04/22/2012 05:09 PM, Gleb Natapov wrote:
On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi Kivity wrote:
On 04/22/2012
From: Konstantin Weitz weitz...@de.ibm.com
This patch implements the directed yield hypercall found on other
System z hypervisors. It delegates execution time to the virtual cpu
specified in the instruction's parameter.
Useful to avoid long spinlock waits in the guest.
Signed-off-by: Konstantin
From: Cornelia Huck cornelia.h...@de.ibm.com
Handle the mandatory intercept SET CLOCK PROGRAMMABLE FIELD
instruction.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
arch/s390/kvm/intercept.c |1 +
arch/s390/kvm/kvm-s390.h |1 +
arch/s390/kvm/priv.c | 31
Let userspace know the number of supported cpus fro kvm.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/kvm-s390.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index fd98914..0054cb0 100644
---
Avi, Marcelo,
here are 3 patches for kvm on s390.
One patch implements diag 9c (directed yield).
Tthe two other patches implement a missing instruction and
KVM_CAP_MAX_VCPUS.
ALl 3 are targeted for the next merge window.
Thanks
Christian
Christian Borntraeger (1):
kvm-s390: implement
On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote:
Hi,
On Sun, Apr 22, 2012 at 05:20:59PM +0300, Gleb Natapov wrote:
On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote:
On 04/22/2012 05:09 PM, Gleb Natapov wrote:
On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi
Fixed two problems we were having; USB stability, and Mouse-grab.
Thanks to Gerd Hoffman for fixing the USB. Our systems should be much
better now.
Simon
S.J.P.O'Riordan
Software Engineer,
MAPD Renishaw
Tel.01453 523701
To Gert Hoffman for fixing the USB in 1.0.1 Qemu-kvm
S.J.P.O'Riordan
Software Engineer,
MAPD Renishaw
Tel.01453 523701
--
This email and any attachments are confidential and are for the use of the
Hi,
On Tue, Apr 24, 2012 at 10:52:24AM +0300, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote:
The 440fx spec mentions: The address range from the top of main DRAM to 4
Gbytes (top of physical memory space supported by the 440FX PCIset) is
normally
Hi,
On Mon, Apr 23, 2012 at 07:37:51PM -0400, Kevin O'Connor wrote:
On Thu, Apr 19, 2012 at 04:08:41PM +0200, Vasilis Liaskovitis wrote:
The memory device generation is guided by qemu paravirt info. Seabios
first uses the info to setup SRAT entries for the hotplug-able memory
slots.
To Gert Hoffman for fixing the USB in 1.0.1 Qemu-kvm.
Simon
--
This email and any attachments are confidential and are for the use of the
addressee only. If you are not the addressee, you must not
htmlheadstyle body {height: 100%; color:#00; font-size:10pt;
font-family:Verdana;}/style/headbody/body/html
Dr. Bode Message.doc
Description: application/ole-storage
On Tue, Apr 24, 2012 at 10:24:51AM +0200, Vasilis Liaskovitis wrote:
Hi,
On Tue, Apr 24, 2012 at 10:52:24AM +0300, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote:
The 440fx spec mentions: The address range from the top of main DRAM to 4
Gbytes
On 04/24/2012 10:21 AM, Gleb Natapov wrote:
I was thinking about not having tons of 128MB slots, so we don't have a
configuration that is far from reality. But maybe this thinking is too
conservative.
I think it is good interface to make memory that is specified with -m to
be one
On 04/24/2012 09:37 AM, Xiao Guangrong wrote:
On 04/24/2012 12:16 AM, Avi Kivity wrote:
Using RCU for lockless shadow walking can increase the amount of memory
in use by the system, since RCU grace periods are unpredictable. We also
have an unconditional write to a shared variable
On 04/24/2012 12:19 PM, Avi Kivity wrote:
We need a mb here to avoid that setting vcpu-mode is reordered to the head
of reading/writing spte? (it is safe on x86, but we need a comment at
least?)
I don't think so. Documentation/memory-barriers says:
Any atomic operation that modifies
On 04/24/2012 04:17 AM, Marcelo Tosatti wrote:
On Mon, Apr 23, 2012 at 07:16:52PM +0300, Avi Kivity wrote:
Using RCU for lockless shadow walking can increase the amount of memory
in use by the system, since RCU grace periods are unpredictable. We also
have an unconditional write to a
mtspr/mfspr emulation prints an error message for unknown SPRs. The message
was badly formatted displaying the hex value without 0x prefix. Use decimal
representation in accordance with the manuals, though the Linux headers
annoyingly use hex.
Signed-off-by: Mihai Caraman
Using RCU for lockless shadow walking can increase the amount of memory
in use by the system, since RCU grace periods are unpredictable. We also
have an unconditional write to a shared variable (reader_counter), which
isn't good for scaling.
Replace that with a scheme similar to x86's
On 04/24/2012 05:19 PM, Avi Kivity wrote:
Turned out to be simpler than expected. However, I think there's a problem
with make_all_cpus_request() possible reading an incorrect vcpu-cpu.
It seems possible.
Can we fix it by reading vcpu-cpu when the vcpu is in GUEST_MODE or
On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
From: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt
state.
The presence of these hypercalls is indicated to guest via
On 04/24/2012 12:54 PM, Xiao Guangrong wrote:
On 04/24/2012 05:19 PM, Avi Kivity wrote:
Turned out to be simpler than expected. However, I think there's a
problem
with make_all_cpus_request() possible reading an incorrect vcpu-cpu.
It seems possible.
Can we fix it by reading
On 04/24/2012 06:02 PM, Avi Kivity wrote:
kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
cpumask_set_cpu(cpu, cpus);
}
VCPU 0 send IPI to CPU1, but actually, VCPU1 is running on CPU 2.
It can happen, but it's benign. After migration, vcpu1 will
On 04/24/2012 05:47 PM, Avi Kivity wrote:
static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
{
@@ -2021,17 +2006,17 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
if (list_empty(invalid_list))
On 04/24/2012 01:13 PM, Xiao Guangrong wrote:
On 04/24/2012 05:47 PM, Avi Kivity wrote:
static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
{
@@ -2021,17 +2006,17 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
On 04/23/2012 06:55 PM, Jan Kiszka wrote:
On 2012-04-23 17:32, Avi Kivity wrote:
On 04/10/2012 09:30 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user
On 04/24/2012 10:24 AM, Christian Borntraeger wrote:
From: Konstantin Weitz weitz...@de.ibm.com
This patch implements the directed yield hypercall found on other
System z hypervisors. It delegates execution time to the virtual cpu
specified in the instruction's parameter.
Useful to avoid
On 04/24/2012 10:24 AM, Christian Borntraeger wrote:
Let userspace know the number of supported cpus fro kvm.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/kvm-s390.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/s390/kvm/kvm-s390.c
On 2012-04-24 13:57, Avi Kivity wrote:
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ
Some cosmetics for the API docs and the documentations for the PIT
IOCTLs are the foundation. On top comes the previously posted patch for
a separate PIT interrupt injection kthread, just augmented by some
documentation.
This series depends on the application or folding-in of
We can't run PIT IRQ injection work in the interrupt context of the host
timer. This would allow the user to influence the handler complexity by
asking for a broadcast to a large number of VCPUs. Therefore, this work
was pushed into workqueue context in 9d244caf2e. However, this prevents
Add descriptions for KVM_CREATE_PIT2 and KVM_GET/SET_PIT2.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Documentation/virtual/kvm/api.txt | 57 +
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
This helps to identify sections and it also fixes the numbering from
4.54 to 4.61.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Documentation/virtual/kvm/api.txt | 99 ++---
1 files changed, 92 insertions(+), 7 deletions(-)
diff --git
On 24/04/12 14:04, Avi Kivity wrote:
[...]
+int tid;
+int i;
+
+tid = vcpu-run-s.regs.gprs[(vcpu-arch.sie_block-ipa 0xf0) 4];
+vcpu-stat.diagnose_9c++;
+VCPU_EVENT(vcpu, 5, diag time slice end directed to %d, tid);
+
+if (tid == vcpu-vcpu_id)
+return
@@ -136,6 +136,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_SYNC_REGS:
r = 1;
break;
+case KVM_CAP_NR_VCPUS:
+r = KVM_MAX_VCPUS;
+break;
default:
r = 0;
}
This looks like a bugfix, but
From: Konstantin Weitz weitz...@de.ibm.com
This patch implements the directed yield hypercall found on other
System z hypervisors. It delegates execution time to the virtual cpu
specified in the instruction's parameter.
Useful to avoid long spinlock waits in the guest.
Signed-off-by: Konstantin
On 04/24/2012 03:07 PM, Jan Kiszka wrote:
On 2012-04-24 13:57, Avi Kivity wrote:
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI
On 04/24/2012 03:47 PM, Christian Borntraeger wrote:
btw, a better place might be in kvm_devel_ioctl_check_extension_generic().
Possibly yes. Dont know if there are architecture specific reasons to use
something different than KVM_MAX_VCPUS.
Okay, I'll fold the implementations unless
On 04/24/2012 03:55 PM, Christian Borntraeger wrote:
From: Konstantin Weitz weitz...@de.ibm.com
This patch implements the directed yield hypercall found on other
System z hypervisors. It delegates execution time to the virtual cpu
specified in the instruction's parameter.
Useful to avoid
On 2012-04-24 14:59, Avi Kivity wrote:
On 04/24/2012 03:07 PM, Jan Kiszka wrote:
On 2012-04-24 13:57, Avi Kivity wrote:
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is
Hi all,
I saw the following assert after chaning display resolution. This might
be the cause, but i am not sure. Threaded VNC is enabled.
Anyone ever seen this?
qemu-kvm-1.0: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) -
On Tue, Apr 24, 2012 at 03:24:31PM +0200, Peter Lieven wrote:
Hi all,
I saw the following assert after chaning display resolution. This might be
the cause, but i am not sure. Threaded VNC is enabled.
Anyone ever seen this?
qemu-kvm-1.0: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
On 24.04.2012 15:34, Alon Levy wrote:
On Tue, Apr 24, 2012 at 03:24:31PM +0200, Peter Lieven wrote:
Hi all,
I saw the following assert after chaning display resolution. This might be
the cause, but i am not sure. Threaded VNC is enabled.
Anyone ever seen this?
qemu-kvm-1.0: malloc.c:3096:
On 04/19/2012 02:06 PM, Gleb Natapov wrote:
The patch introduces a bitmap that will hold reasons apic should be
checked during vmexit. This is in a preparation for vp eoi patch
that will add one more check on vmexit. With the bitmap we can do
if(apic_attention) to check everything
On 04/17/2012 11:41 AM, Stefan Hajnoczi wrote:
The disk corruption experienced was indeed lost data -- an fsck was
necessary for 4 of the guests to boot at all in RW mode, they first came up
read only. In the case of one of the guests there was actually files data /
data lost after fsck
Juan Quintela quint...@redhat.com wrote:
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
As there are no topic, call is cancelled.
Happy hacking, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 04/23/2012 06:37 PM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Although ModRM byte is read for group decoding, it is soon pushed back
to make decode_modrm() fetch it later.
We should consistently read it, only once, in decode_opcode() instead.
On 04/23/2012 06:31 PM, Takuya Yoshikawa wrote:
Takuya Yoshikawa (4):
KVM: x86 emulator: Introduce ctxt-op_prefix for 0x66 prefix
KVM: x86 emulator: Make prefix decoding a separate function
KVM: x86 emulator: Make opcode decoding a separate function
I don't see the benefit for the
On 04/23/2012 11:47 AM, Jan Kiszka wrote:
The upstream version provides the same feature plus proper support for
the PC speaker port while the in-kernel PIT is enabled.
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send
On Tue, 24 Apr 2012 17:10:08 +0300
Avi Kivity a...@redhat.com wrote:
+ if (!modrm_fetched (ctxt-d ModRM))
+ ctxt-modrm = insn_fetch(u8, ctxt);
Instead of adding yet another conditional, how about doing something like
if ((c-d ModRM) || (gtype == Group) || (gtype ==
Add descriptions for KVM_CREATE_PIT2 and KVM_GET/SET_PIT2.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Documentation/virtual/kvm/api.txt | 63 +
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
Some cosmetics for the API docs and the documentations for the PIT
IOCTLs are the foundation. On top comes the previously posted patch for
a separate PIT interrupt injection kthread, just augmented by some
documentation.
This series depends on the application or folding-in of
We can't run PIT IRQ injection work in the interrupt context of the host
timer. This would allow the user to influence the handler complexity by
asking for a broadcast to a large number of VCPUs. Therefore, this work
was pushed into workqueue context in 9d244caf2e. However, this prevents
This helps to identify sections and it also fixes the numbering from
4.54 to 4.61.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Documentation/virtual/kvm/api.txt | 99 ++---
1 files changed, 92 insertions(+), 7 deletions(-)
diff --git
On Tue, 24 Apr 2012 17:11:54 +0300
Avi Kivity a...@redhat.com wrote:
On 04/23/2012 06:31 PM, Takuya Yoshikawa wrote:
Takuya Yoshikawa (4):
KVM: x86 emulator: Introduce ctxt-op_prefix for 0x66 prefix
KVM: x86 emulator: Make prefix decoding a separate function
KVM: x86 emulator: Make
I think the code will me more readable, and less obvious that is was
copied from kvm_vcpu_on_spin(), if you put all the processing outside
the loop, except for matching the vpu itself.
So the code reads
find a vcpu
obtain the task
do the yield
instead of looking like you're
On 2012-04-23 22:02, Eduardo Habkost wrote:
On Mon, Apr 23, 2012 at 06:31:25PM +0200, Jan Kiszka wrote:
On 2012-04-23 16:48, Eduardo Habkost wrote:
Trying to summarize the points above:
Groups (A) and (B) are:
A) a feature that KVM supports and emulate by itself and can be enabled
by
On 04/24/2012 06:47 PM, Christian Borntraeger wrote:
I think the code will me more readable, and less obvious that is was
copied from kvm_vcpu_on_spin(), if you put all the processing outside
the loop, except for matching the vpu itself.
So the code reads
find a vcpu
obtain
On 24/04/12 18:15, Avi Kivity wrote:
instead of looking like you're doing the processing for every vcpu. The
loop is just a slow lookup which might some day be replaced by a table
lookup.
Ok. We might also have a kvm_vcpu_on_spin_directed in common code,
Would you prefer that?
You mean
On 04/24/2012 07:21 PM, Christian Borntraeger wrote:
On 24/04/12 18:15, Avi Kivity wrote:
instead of looking like you're doing the processing for every vcpu. The
loop is just a slow lookup which might some day be replaced by a table
lookup.
Ok. We might also have a
On 04/23/2012 10:43 PM, Stephen Rothwell wrote:
Hi all,
There will probably be no linux-next release until April 30 as I am
taking a break.
Changes since 20120423:
on i386:
CC [M] arch/x86/kvm/emulate.o
arch/x86/kvm/emulate.c: Assembler messages:
arch/x86/kvm/emulate.c:4122: Error:
(CCing Andre Przywara, in case he can help to clarify what's the
expected meaning of -cpu host)
On Tue, Apr 24, 2012 at 06:06:55PM +0200, Jan Kiszka wrote:
On 2012-04-23 22:02, Eduardo Habkost wrote:
On Mon, Apr 23, 2012 at 06:31:25PM +0200, Jan Kiszka wrote:
However, that was how I
On Mon, Apr 16, 2012 at 09:34:41AM +0100, Stefan Hajnoczi wrote:
On Sun, Apr 15, 2012 at 5:16 AM, Ron Edison r...@idthq.com wrote:
The server is a Dell R710 with an H700 controller with 1gb of nvcache.
Writeback cache is enabled on the controller. There is a mix of linux and
windows
Changlong:
- split the meaning of SPTE_ALLOW_WRITE and rename it to SPTE_MMU_WRITEABLE
- introduce a middle patch that update spte under the protection of mmu-lock
for better review.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
The reture value of __rmap_write_protect is either 1 or 0, use
true/false instead of these
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
Introduce a common function to abstract spte write-protect to
cleanup the code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 60 ++-
1 files changed, 35 insertions(+), 25 deletions(-)
diff --git
This bit indicates whether the gpte of this spte is writable
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e70ff38..46bde3f
If this bit is set, it means the W bit of the spte is cleared due
to shadow page table protection
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 55 +++-
1 files changed, 37 insertions(+), 18 deletions(-)
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is
only modify the access bit which can be done out of mmu-lock
Currently, in order to simplify the code, we only fix the page fault
caused by write-protect on the
All the information we need on the fast page fault path is
SPTE_HOST_WRITEABLE bit, SPTE_MMU_WRITEABLE bit and SPTE_WRITE_PROTECT bit
on spte, actually, all these bits can be protected by cmpxchg
But, we need carefully handle the paths which depend on spte.W bit, it will
be documented in
To see what happen on this path and help us to optimize it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |2 ++
arch/x86/kvm/mmutrace.h | 41 +
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git
Document fast page fault and mmu-lock in locking.txt
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
Documentation/virtual/kvm/locking.txt | 152 -
1 files changed, 151 insertions(+), 1 deletions(-)
diff --git
mtspr/mfspr emulation prints an error message for unknown SPRs. The message
was badly formatted displaying the hex value without 0x prefix. Use decimal
representation in accordance with the manuals, though the Linux headers
annoyingly use hex.
Signed-off-by: Mihai Caraman
78 matches
Mail list logo
