From: Alexander Graf a...@csgraf.de
While converting the kzalloc we used to allocate our vcpu struct to
vmalloc, I forgot to memset the contents to zeros. That broke quite
a lot.
This patch memsets it to zero again.
Signed-off-by: Alexander Graf a...@csgraf.de
Signed-off-by: Avi Kivity
From: Alexander Graf a...@csgraf.de
When we destory a vcpu, we should also make sure to kill all pending
timers that could still be up. When not doing this, hrtimers might
dereference null pointers trying to call our code.
This patch fixes spontanious kernel panics seen after closing VMs.
From: Jan Kiszka jan.kis...@siemens.com
We intercept #BP while in guest debugging mode. As VM exits due to
intercepted exceptions do not necessarily come with valid
idt_vectoring, we have to update event_exit_inst_len explicitly in such
cases. At least in the absence of migration, this ensures
From: Jan Kiszka jan.kis...@siemens.com
This restores the deferred VCPU kicking before 956f97cf. We need this
over -rt as wake_up* requires non-atomic context in this configuration.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git
From: Jan Kiszka jan.kis...@siemens.com
RF is not required for injecting TF as the latter will trigger only
after an instruction execution anyway. So do not touch RF when arming or
disarming guest single-step mode.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity
From: Jan Kiszka jan.kis...@siemens.com
When in guest debugging mode, we have to reinject those #BP software
exceptions that are caused by guest-injected INT3. As older AMD
processors do not support the required nRIP VMCB field, try to emulate
it by moving RIP past the instruction on exception
From: Jan Kiszka jan.kis...@siemens.com
Based on Gleb's suggestion: Add a helper kvm_is_linear_rip that matches
a given linear RIP against the current one. Use this for guest
single-stepping, more users will follow.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity
From: Jan Kiszka jan.kis...@siemens.com
This marks the guest single-step API improvement of 94fe45da and
91586a3b with a capability flag to allow reliable detection by user
space.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Cc: sta...@kernel.org (2.6.33)
Signed-off-by: Avi Kivity
From: Jan Kiszka jan.kis...@siemens.com
Call directly into the vendor services for getting/setting rflags in
emulate_instruction to ensure injected TF survives the emulation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git
Some weeks ago, OHMURA Kei revised the qemu-kvm's
dirty bitmap scan by accessing the bitmap as an
unsigned long array.
By reviewing this work more, we notice that kernel
side is doing a similar thing to check the bitmap is
all clean or not.
So I made a patch which makes the get dirty log ioctl
This patch changes the get dirty log ioctl to inform the
already scanned clean bitmap area to userspace.
Without this patch, the information obtained by the scan in
kernel is just ignored. To fix this, we use the return value
of ioctl call as a hint of from where we should scan.
Be careful that
On 02/24/2010 10:43 AM, Takuya Yoshikawa wrote:
Some weeks ago, OHMURA Kei revised the qemu-kvm's
dirty bitmap scan by accessing the bitmap as an
unsigned long array.
By reviewing this work more, we notice that kernel
side is doing a similar thing to check the bitmap is
all clean or not.
So I
On 02/24/2010 10:55 AM, Avi Kivity wrote:
On 02/24/2010 10:43 AM, Takuya Yoshikawa wrote:
Some weeks ago, OHMURA Kei revised the qemu-kvm's
dirty bitmap scan by accessing the bitmap as an
unsigned long array.
By reviewing this work more, we notice that kernel
side is doing a similar thing to
On 02/24/2010 11:20 AM, Takuya Yoshikawa wrote:
Another issue I am thinking is the x86's bitmap allocation. Doing
vmalloc()
every time is not nice, though I know it's needed.
Right, that's why I want to move the allocation to userspace.
btw, one idea I had was to allocate the bitmap in
Avi Kivity wrote:
Result:
...
kvm_get_map(slot 0): r=3, slot.len=655360(2)
kvm_get_map(slot 1): r= 2044, slot.len= 535822336(2044)
kvm_get_map(slot 2): r=1, slot.len=131072(0)
kvm_get_map(slot 3): r=1, slot.len=131072(0)
kvm_get_map(slot 4): r=1, slot.len=
On 02/24/2010 11:41 AM, Jan Kiszka wrote:
Thomas Gleixner wrote:
On Tue, 23 Feb 2010, Jan Kiszka wrote:
Thomas Gleixner wrote:
The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert
them to raw_spinlock. No change for !RT kernels.
Doesn't fly for
Avi Kivity wrote:
On 02/24/2010 11:41 AM, Jan Kiszka wrote:
Thomas Gleixner wrote:
On Tue, 23 Feb 2010, Jan Kiszka wrote:
Thomas Gleixner wrote:
The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert
them to raw_spinlock. No change for !RT kernels.
On 02/24/2010 11:45 AM, Takuya Yoshikawa wrote:
Avi Kivity wrote:
Result:
...
kvm_get_map(slot 0): r=3, slot.len=655360(2)
kvm_get_map(slot 1): r= 2044, slot.len= 535822336(2044)
kvm_get_map(slot 2): r=1, slot.len=131072(0)
kvm_get_map(slot 3): r=1, slot.len=131072(0)
On 02/24/2010 11:54 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 11:41 AM, Jan Kiszka wrote:
Thomas Gleixner wrote:
On Tue, 23 Feb 2010, Jan Kiszka wrote:
Thomas Gleixner wrote:
The i8254/i8259 locks need to be real spinlocks on
Avi Kivity wrote:
Seems to confirm - not much can be skipped.
kvm_get_map(slot 1): r= 2044, slot.len= 535822336(2044)
Am I wrong? in this case, the return value is suggesting
we can skip every 2044(the value in the bracket) bitmap check, right?
Er, I was wrong, I thought the value in the
Avi Kivity wrote:
On 02/24/2010 11:54 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 11:41 AM, Jan Kiszka wrote:
Thomas Gleixner wrote:
On Tue, 23 Feb 2010, Jan Kiszka wrote:
Thomas Gleixner wrote:
The i8254/i8259 locks need to be real
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
If there are such call paths, for sure. What concrete path(s) do you
have in mind?
vcpu_enter_guest() -
On 02/22/2010 05:52 PM, Alexander Graf wrote:
While converting the kzalloc we used to allocate our vcpu struct to
vmalloc, I forgot to memset the contents to zeros. That broke quite
a lot.
This patch memsets it to zero again.
Applied, thanks.
--
error compiling committee.c: too many
On 02/22/2010 05:52 PM, Alexander Graf wrote:
When we destory a vcpu, we should also make sure to kill all pending
timers that could still be up. When not doing this, hrtimers might
dereference null pointers trying to call our code.
This patch fixes spontanious kernel panics seen after closing
Avi Kivity wrote:
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
If there are such call paths, for sure. What concrete path(s) do you
have in mind?
On 02/24/2010 12:22 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
If there are such call paths, for sure.
Add decoding of Ep type of argument used by callf/jmpf.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index c9f604b..d288107 100644
Implement jmp far opcode ff/5. It is used by multiboot loader.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d288107..c46a1fe 100644
Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
If there are such call paths, for sure. What concrete path(s) do you
have in mind?
Add check_image.py in scripts folder. It will performance qemu-img info
and qemu-img check.
Add check_image.py as post command of qcow2 variant.
Signed-off-by: Feng Yang fy...@redhat.com
---
client/tests/kvm/scripts/check_image.py | 96 +++
Avi Kivity wrote:
On 02/24/2010 12:22 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
If there are such call
On 02/23/2010 06:47 PM, Jan Kiszka wrote:
Changes in v2:
- Retreat TF emulation patch, waiting for emulator rework
- Spilt out svm_queue_exception moving
- Factor out kvm_is_linear_rip (Saved linear RIP == current RIP?)
- Fixed breakage in INT3 emulation code and addressed review
On 02/24/2010 12:52 PM, Avi Kivity wrote:
On 02/23/2010 06:47 PM, Jan Kiszka wrote:
Changes in v2:
- Retreat TF emulation patch, waiting for emulator rework
- Spilt out svm_queue_exception moving
- Factor out kvm_is_linear_rip (Saved linear RIP == current RIP?)
- Fixed breakage in INT3
Nobody use -monitor stdio option have this problem?
please help, thank you.
After upgrade to snapshot
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=snapshot;h=db311e8619d310bd7729637b702581d3d8565049;sf=tgz;,
i can not see the -vga std screen, kvm will start the vnc instead vga.
my kvm
On 02/24/2010 12:44 AM, Erik Rull wrote:
Hi all,
I've only a core2duo with VT, is it somehow possible to use the PCI
device assignment without VT-d?
That would be great because I cannot upgrade the Mainboard for my system.
Not really. There was some work to allow a single unmodified guest
Quoting Hao, Xudong xudong@intel.com:
chkconfig --level 35 kvm off
Hi Hao,
Thanks for your advice.
Please help me to understand:-
1)
chkconfig - is a small package to update and query runlevel info for
system services
--level 35 specifies runlevels 3 and 5
That means on next
Avi Kivity wrote:
On 02/24/2010 12:28 PM, Jan Kiszka wrote:
Jan Kiszka wrote:
Avi Kivity wrote:
On 02/24/2010 12:13 PM, Jan Kiszka wrote:
I see. Won't we hit the same issue when we call pic functions from
atomic context during the guest entry sequence?
There is no need for the this hack anymore, initialization is now robust
against reordering as it doesn't try to write the VCPU state on its own.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pc.c |5 -
target-i386/helper.c |2 ++
2 files changed, 2
Setting the boot CPU ID is arch-specific KVM stuff. So push it where it
belongs to.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pc.c|3 ---
qemu-kvm-x86.c |3 ++-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 8b5af35..971ae70
Do not write nmi_pending, sipi_vector, and mpstate unless we at least go
through a reset. And TSC as well as KVM wallclocks should only be
written on full sync, otherwise we risk to drop some time on during
state read-modify-write.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm.h
Push reading/writing of vcpu_events into kvm_arch_load/save_regs to
avoid KVM-specific hooks in generic code.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm.h |2 --
qemu-kvm-x86.c|6 --
target-i386/kvm.c |4 ++--
target-i386/machine.c |6
As we hard-wire the BSP to CPU 0 anyway and cpuid_apic_id equals
cpu_index, cpu_is_bsp can also be based on the latter directly. This
will help an early user of it: KVM while initializing mp_state.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pc.c |3 ++-
1 files changed, 2
This grand cleanup drops all reset and vmsave/load related
synchronization points in favor of four(!) generic hooks:
- cpu_synchronize_all_states in qemu_savevm_state_complete
(initial sync from kernel before vmsave)
- cpu_synchronize_all_post_init in qemu_loadvm_state
(writeback after
Drop kvm_load_tsc in favor of level-dependent writeback in
kvm_arch_load_regs. KVM's PV clock MSRs fall in the same category and
should therefore only be written back on full sync.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm-x86.c| 19 +--
qemu-kvm.h
The APIC is part of the VCPU state, so trigger its readout and writeback
from kvm_arch_save/load_regs. Thanks to the transparent sync on reset
and vmsave/load, we can also drop explicit sync code, reducing the diff
to upstream.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c
This add-on patch to recent guest debugging refactorings adds the
requested awareness for KVM_CAP_X86_ROBUST_SINGLESTEP to both the
upstream as well as qemu-kvm's own code. Fortunately, code sharing
increased once again.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c |
Push mpstate reading/writing into kvm_arch_load/save_regs and, on x86,
properly synchronize with halted in the accessor functions.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c |7 ---
qemu-kvm-ia64.c |4 +-
qemu-kvm-x86.c| 102
Add io memory to test device. This is needed by emulator test.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/testdev.c b/hw/testdev.c
index ac5b9cd..ad34e43 100644
--- a/hw/testdev.c
+++ b/hw/testdev.c
@@ -34,14 +34,62 @@ static void test_device_irq_line(void *opaque, uint32_t
Let's proceed with cleaning up the VCPU state writeback. The differences
to v2 are:
- included guest debugging update patch and rebased on top of it
- renamed KVM_PUT_ASYNC_STATE-KVM_PUT_RUNTIME_STATE and added comments
- fixed mp_state corruption due to early use of cpu_is_bsp
Some patches
On Sun, Feb 21, 2010 at 02:09:15PM +0100, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not notice
this? svm loads the bitmap during
Hi Chris,
On 02/22/2010 04:52 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
I thought it might be easier to use the wiki for collecting agenda items
instead of polling the list. It also us do a little bit more long term
planning.
This patch removes whitespace errors, fixes comment formats
and most of checkpatch warnings. Now vim does not show
c-space-errors anymore.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 148 ---
1 files changed, 81
This patch implements the emulation of the vm_cr msr for
nested svm.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/include/asm/svm.h |4
arch/x86/kvm/svm.c | 29 -
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git
Hi,
here is another set of patches I collected in the last days while trying
to get Hyper-V running with nested svm. I was not successful yet but the
patches in this set make sense anyway :-)
The patches fix coding style issues which annoyed me for some time
because my vim shows all
Hyper-V as a guest wants to write this bit. This patch
ignores it.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/x86.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2c24cb5..31d44c1 100644
---
The vcpu-arch.cr0 variable is already set in the
architecture specific set_cr0 callbacks. There is no need to
set it in the common code.
This allows the architecture code to keep the old arch.cr0
value if it wants. This is required for nested svm to decide
if a selective_cr0 exit needs to be
A recent change broke tracing of the nested vmcb address. It
was reported as 0 all the time. This patch fixes it.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c
This patch optimizes the way the msrpm of the host and the
guest are merged. The old code merged the 2 msrpm pages
completly. This code needed to touch 24kb of memory for that
operation. The optimized variant this patch introduces
merges only the parts where the host msrpm may contain zero
bits.
If we have the following situation with nested svm:
1. Host KVM intercepts cr0 writes
2. Guest hypervisor intercepts only selective cr0 writes
Then we get an cr0 write intercept which is handled on the
host. But that intercepts may actually be a selective cr0
intercept for the guest. This patch
When injecting an vmexit.intr into the nested hypervisor
there might be leftover values in the exit_info fields.
Clear them to not confuse nested hypervisors.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
This patch adds a tracepoint to get information about the
most important intercept bitmasks from the nested vmcb.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c |5 +
arch/x86/kvm/trace.h | 22 ++
arch/x86/kvm/x86.c |1 +
3 files
This patch implements the NMI intercept checking for nested
svm.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b821b2f..9759d9f
On Wed, Feb 24, 2010 at 06:59:10PM +0100, Joerg Roedel wrote:
This patch removes whitespace errors, fixes comment formats
and most of checkpatch warnings. Now vim does not show
This means actually errors. The warnings left in this file are
completly
On 24.02.2010, at 18:59, Joerg Roedel wrote:
This patch optimizes the way the msrpm of the host and the
guest are merged. The old code merged the 2 msrpm pages
completly. This code needed to touch 24kb of memory for that
operation. The optimized variant this patch introduces
merges only the
On Wed, Feb 24, 2010 at 08:27:50PM +0100, Alexander Graf wrote:
+ static const u32 msrpm_offsets[] = {
+ 0x002c, /* SYSENTER_CS */
+
+ 0x0038, /* LASTBRANCHFROMIP
+ LASTBRANCHTOIP
+ LASTINTFROMIP
+
On 24.02.2010, at 20:58, Avi Kivity wrote:
On 02/24/2010 09:37 PM, Joerg Roedel wrote:
Isn't there such a list around somewhere already? We really should
only keep this list once throughout the whole code. If necessary, just
create the list on the fly when bits get set in the msrpm.
On 02/24/2010 05:23 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:09:15PM +0100, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will
Port qemu-kvm's -mem-path and -mem-prealloc options. These are useful
for backing guest memory with huge pages via hugetlbfs.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
CC: john cooper john.coo...@redhat.com
Index: qemu-kvm/cpu-all.h
-mem-path option allows file backed guest memory.
--
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
From: Avi Kivity a...@redhat.com
Instead of allocating a separate chunk for the first 640KB and another
for 1MB+, allocate one large chunk. This plays well in terms of alignment
and size with large pages.
Signed-off-by: Avi Kivity a...@redhat.com
(cherry picked from commit
On Wed, Feb 24, 2010 at 03:17:48PM +0100, Jan Kiszka wrote:
Let's proceed with cleaning up the VCPU state writeback. The differences
to v2 are:
- included guest debugging update patch and rebased on top of it
- renamed KVM_PUT_ASYNC_STATE-KVM_PUT_RUNTIME_STATE and added comments
- fixed
On Wed, Feb 24, 2010 at 03:17:55PM +0100, Jan Kiszka wrote:
Drop kvm_load_tsc in favor of level-dependent writeback in
kvm_arch_load_regs. KVM's PV clock MSRs fall in the same category and
should therefore only be written back on full sync.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
On Wed, Feb 24, 2010 at 03:17:53PM +0100, Jan Kiszka wrote:
Do not write nmi_pending, sipi_vector, and mpstate unless we at least go
through a reset. And TSC as well as KVM wallclocks should only be
written on full sync, otherwise we risk to drop some time on during
state read-modify-write.
On Wed, Feb 24, 2010 at 03:17:52PM +0100, Jan Kiszka wrote:
Push mpstate reading/writing into kvm_arch_load/save_regs and, on x86,
properly synchronize with halted in the accessor functions.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
@@ -1290,6 +1318,7 @@ int
On Thu, Feb 25, 2010 at 12:45:55AM +0100, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:55PM +0100, Jan Kiszka wrote:
Drop kvm_load_tsc in favor of level-dependent writeback in
kvm_arch_load_regs. KVM's PV clock MSRs fall in the same category and
should therefore
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:53PM +0100, Jan Kiszka wrote:
Do not write nmi_pending, sipi_vector, and mpstate unless we at least go
through a reset. And TSC as well as KVM wallclocks should only be
written on full sync, otherwise we risk to drop some time on during
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:48PM +0100, Jan Kiszka wrote:
Let's proceed with cleaning up the VCPU state writeback. The differences
to v2 are:
- included guest debugging update patch and rebased on top of it
- renamed KVM_PUT_ASYNC_STATE-KVM_PUT_RUNTIME_STATE and
Marcelo Tosatti wrote:
On Thu, Feb 25, 2010 at 12:45:55AM +0100, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:55PM +0100, Jan Kiszka wrote:
Drop kvm_load_tsc in favor of level-dependent writeback in
kvm_arch_load_regs. KVM's PV clock MSRs fall in the same category
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:52PM +0100, Jan Kiszka wrote:
Push mpstate reading/writing into kvm_arch_load/save_regs and, on x86,
properly synchronize with halted in the accessor functions.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
@@ -1290,6 +1318,7 @@ int
Hello, Lucas, I think there are two advantages of such a private bridge:
1). With private bridge, not paying attention to the conflict of guest's mac
address.
2). segregating from public network which host locates.
- Lucas Meneghel Rodrigues l...@redhat.com 写道：
On Tue, 2010-02-23 at
Marcelo introduced gfn_to_hva_memslot() when he implemented
gfn_to_pfn_memslot(). Let's use this for gfn_to_hva() too.
Note: also remove parentheses next to return as checkpatch said to do.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 12
That's right.
I run it on RHEL system, F12 should be same, you can have a try.
sati...@pacific.net.hk wrote:
Quoting Hao, Xudong xudong@intel.com:
chkconfig --level 35 kvm off
Hi Hao,
Thanks for your advice.
Please help me to understand:-
1)
chkconfig - is a small
Quoting Hao, Xudong xudong@intel.com:
That's right.
I run it on RHEL system, F12 should be same, you can have a try.
Hi Hao,
$ lsmod | grep kvm
kvm_amd38452 0
kvm 163952 1 kvm_amd
# chkconfig --level 35 kvm off
error reading information on service
On Thu, Feb 25, 2010 at 12:58:26AM +0100, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Thu, Feb 25, 2010 at 12:45:55AM +0100, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Wed, Feb 24, 2010 at 03:17:55PM +0100, Jan Kiszka wrote:
Drop kvm_load_tsc in favor of level-dependent writeback in
sati...@pacific.net.hk wrote:
Quoting Hao, Xudong xudong@intel.com:
# chkconfig --level 35 kvm off
error reading information on service kvm: No such file or directory
I'm not try F12 maybe some pakeage missed. just googled then find answer.
so if you get this error also and you have a
On Thu, Feb 25, 2010 at 12:25:07PM +0800, sati...@pacific.net.hk wrote:
Quoting Hao, Xudong xudong@intel.com:
That's right.
I run it on RHEL system, F12 should be same, you can have a try.
Hi Hao,
$ lsmod | grep kvm
kvm_amd38452 0
kvm 163952 1
On 02/24/2010 06:02 PM, Anthony Liguori wrote:
Hi Chris,
On 02/22/2010 04:52 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
I thought it might be easier to use the wiki for collecting agenda
items instead of polling the list. It also us do a little
On 02/22/2010 05:52 PM, Alexander Graf wrote:
While converting the kzalloc we used to allocate our vcpu struct to
vmalloc, I forgot to memset the contents to zeros. That broke quite
a lot.
This patch memsets it to zero again.
Applied, thanks.
--
error compiling committee.c: too many
88 matches
Mail list logo
