Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
- Yolkfull Chow yz...@redhat.com wrote:
Hi Michael, I just have some comments on what you changed on
stress_boot. :-)
On Mon, Aug 03, 2009 at 02:58:21AM +0300, Michael Goldish wrote:
Take an additional parameter 'clone_address_index_base' which
indicates the
initial value for
On 08/03/2009 04:52 AM, Kent Tong wrote:
Hi,
It seems to be an unsettled issue, but, would any kind soul suggest the current
best practice for setting the clock in Ubuntu Linux and Windows guests?
For Linux the best source clock is the kvm pv clock (exist from 2.6.27
and above).
For
On Mon, Aug 03, 2009 at 02:45:23AM -0400, Michael Goldish wrote:
- Yolkfull Chow yz...@redhat.com wrote:
Hi Michael, I just have some comments on what you changed on
stress_boot. :-)
On Mon, Aug 03, 2009 at 02:58:21AM +0300, Michael Goldish wrote:
Take an additional
- Yolkfull Chow yz...@redhat.com wrote:
On Mon, Aug 03, 2009 at 02:45:23AM -0400, Michael Goldish wrote:
- Yolkfull Chow yz...@redhat.com wrote:
Hi Michael, I just have some comments on what you changed on
stress_boot. :-)
On Mon, Aug 03, 2009 at 02:58:21AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Dor Laor wrote:
On 08/03/2009 04:52 AM, Kent Tong wrote:
Hi,
It seems to be an unsettled issue, but, would any kind soul suggest
the current
best practice for setting the clock in Ubuntu Linux and Windows guests?
For Linux the best
On 08/03/2009 11:11 AM, Antoine Martin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Dor Laor wrote:
On 08/03/2009 04:52 AM, Kent Tong wrote:
Hi,
It seems to be an unsettled issue, but, would any kind soul suggest
the current
best practice for setting the clock in Ubuntu Linux
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 2a6faa2..c743186 100755
--- a/configure
+++ b/configure
@@ -1818,10 +1818,10 @@ if test $fdt = yes ; then
echo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
It seems to be an unsettled issue, but, would any kind soul suggest
the current
best practice for setting the clock in Ubuntu Linux and Windows guests?
For Linux the best source clock is the kvm pv clock (exist from 2.6.27
and above).
#
Remove debugfs file if kvm_arch_init() return error
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
virt/kvm/kvm_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2884baf..6299208 100644
---
On 06/30/2009 09:58 PM, Dor Laor wrote:
On 06/30/2009 02:11 PM, Yolkfull Chow wrote:
Signed-off-by: Yolkfull Chowyz...@redhat.com
---
client/tests/kvm/kvm.py |1 +
client/tests/kvm/kvm_tests.cfg.sample | 56
client/tests/kvm/kvm_tests.py |
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify corresponding IP
ranges.
- VMs are always given MAC addresses from the user specified MAC ranges.
- MAC address ranges must be unique to each host running
On 08/03/2009 12:09 PM, Antoine Martin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
It seems to be an unsettled issue, but, would any kind soul suggest
the current
best practice for setting the clock in Ubuntu Linux and Windows guests?
For Linux the best source clock is the kvm pv
- Dor Laor dl...@redhat.com wrote:
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify
corresponding IP
ranges.
- VMs are always given MAC addresses from the user specified MAC
ranges.
-
On 08/03/2009 12:19 PM, Yolkfull Chow wrote:
On 06/30/2009 09:58 PM, Dor Laor wrote:
On 06/30/2009 02:11 PM, Yolkfull Chow wrote:
Signed-off-by: Yolkfull Chowyz...@redhat.com
---
client/tests/kvm/kvm.py | 1 +
client/tests/kvm/kvm_tests.cfg.sample | 56
Sheng Yang wrote:
Copy u64 from guest result in chaos.
Not doing so, while the ABI as been defined as u64, will surely result
in chaos as well - just different one. I'm recalling the problems Alex
recently ran into on big-endian PowerPC and sizeof(userland_long) !=
sizeof(kernel_long).
Also
On 07/28/2009 11:05 PM, Glauber Costa wrote:
use cpuid code from upstream. By doing that, we lose the following snippet
in kvm_get_supported_cpuid():
ret |= 1 12; /* MTRR */
ret |= 1 16; /* PAT */
ret |= 1 7; /* MCE */
ret |= 1 14; /* MCA */
A quick search in mailing
On 7/27/09, Michael Goldish mgold...@redhat.com wrote:
It looks like you're using opensshd with cygwin -- not the one we normally
install on guests, but rather one that outputs colorful text. Is that right?
Which server are you using exactly?
There's not much I can do against colorful text,
On 07/28/2009 12:32 PM, Jan Kiszka wrote:
No caller of qemu_cond_wait makes use of this polling anymore. Remove
it.
Applied, thanks.
--
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 08/03/2009 12:39 PM, Michael Goldish wrote:
- Dor Laordl...@redhat.com wrote:
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify
corresponding IP
ranges.
- VMs are always given MAC addresses
On 07/28/2009 05:40 AM, Marcelo Tosatti wrote:
Otherwise the host can spend too long traversing an rmap chain, which
happens under a spinlock.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm
On 07/28/2009 05:41 AM, Marcelo Tosatti wrote:
Otherwise its possible to starve the host by programming lapic timer
with a very high frequency.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm
On 07/21/2009 03:00 AM, Marcelo Tosatti wrote:
Jan,
This was suggested but we thought it might be safer to keep the
get_cpu/put_cpu pair in case -rt kernels require it (which might be
bullshit, but nobody verified).
Thinking about it, it is bullshit:
- me = get_cpu();
On 08/03/2009 09:17 AM, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2
On 08/03/2009 12:10 PM, Xiao Guangrong wrote:
Remove debugfs file if kvm_arch_init() return error
Applied, thanks.
--
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 07/31/2009 09:19 PM, Glauber Costa wrote:
Since commit 89e671e3, extboot is broken due to wrong checksum
The problem is that printf \\$sum syntax will require an octal
representation, so the fix I'm proposing is to convert it first.
Whichever way this gets resolved, please send it
On 07/31/2009 05:15 PM, Kai Zimmer wrote:
qemu-kvm -hda xyz.qcow2 -daemonize -net nic,model=virtio -net tap -k de -m 3584
-smp 2 -mem-path /hugepages -vnc :2
Any ideas what goes wrong here?
All three guests have the same MAC address, so when one talks, you can't
hear the others.
Use
On 08/03/2009 11:39 AM, Jan Kiszka wrote:
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
Applied, thanks.
--
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 majord...@vger.kernel.org
On 07/28/2009 04:49 AM, Glauber Costa wrote:
not a single in-tree user.
Applied, thanks.
--
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 majord...@vger.kernel.org
More majordomo
On Mon, Aug 03, 2009 at 05:19:17PM +0800, Yolkfull Chow wrote:
On 06/30/2009 09:58 PM, Dor Laor wrote:
On 06/30/2009 02:11 PM, Yolkfull Chow wrote:
Signed-off-by: Yolkfull Chowyz...@redhat.com
---
client/tests/kvm/kvm.py |1 +
client/tests/kvm/kvm_tests.cfg.sample | 56
On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote:
On 07/28/2009 11:05 PM, Glauber Costa wrote:
use cpuid code from upstream. By doing that, we lose the following snippet
in kvm_get_supported_cpuid():
ret |= 1 12; /* MTRR */
ret |= 1 16; /* PAT */
ret |= 1 7; /*
On Monday 03 August 2009 20:25:43 Avi Kivity wrote:
On 08/03/2009 09:17 AM, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the
- Dor Laor dl...@redhat.com wrote:
On 08/03/2009 12:39 PM, Michael Goldish wrote:
- Dor Laordl...@redhat.com wrote:
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify
corresponding IP
We are pleased to announce the formation of the AlacrityVM project and
the availability of v0.1 of the code. AlacrityVM is a hypervisor based
on KVM targeted specifically at performance sensitive workloads such as
HPC and real-time.
You can find more information on the AlacrityVM wiki, available
On 08/03/2009 04:22 PM, Glauber Costa wrote:
On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote:
On 07/28/2009 11:05 PM, Glauber Costa wrote:
use cpuid code from upstream. By doing that, we lose the following snippet
in kvm_get_supported_cpuid():
ret |= 1 12; /* MTRR
Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random
On Mon, Aug 03, 2009 at 05:06:28PM +0300, Avi Kivity wrote:
On 08/03/2009 04:22 PM, Glauber Costa wrote:
On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote:
On 07/28/2009 11:05 PM, Glauber Costa wrote:
use cpuid code from upstream. By doing that, we lose the following
On Sun, Aug 2, 2009 at 8:58 PM, Michael Goldishmgold...@redhat.com wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify corresponding IP
ranges.
- VMs are always given MAC addresses from the user specified MAC ranges.
- MAC address ranges must be
On Mon, Aug 3, 2009 at 8:54 AM, sudhir kumarsmalik...@gmail.com wrote:
On 7/27/09, Michael Goldish mgold...@redhat.com wrote:
I know this seems a little messy, but if you wait a little while everything
will sort itself out -- if I understand correctly, we are moving towards
using rss.exe on
On 08/03/2009 04:47 PM, Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by
On 08/03/2009 05:12 PM, Glauber Costa wrote:
If qemu-kvm with this patch works on Fedora 10 (latest kernel) and the
equivalent opensuse and Ubuntu kernels, then we can safely remove the
bug workaround. If not, if we apply the patch we just cause users
needless pain.
Again, since it was
On 08/03/2009 05:04 PM, Anthony Liguori wrote:
Actually, VT mandates that vmcalls can only be done from CPL=0.
That's exactly how I misremembered it. However the docs say
IF not in VMX operation
THEN #UD;
ELSIF in VMX non-root operation
THEN VM exit;
ELSIF (RFLAGS.VM = 1) OR
On 07/30/2009 08:02 PM, Roman Steiner wrote:
hej hej,
i've a question about the virtual time implementation in kvm/qemu.
with the monitor commands stop / continue you can stop and start the
guest system, but the system clock is still running.
i\ve done the following experiment:
* start the
Hello,
This was initially a complaint about kvm-amd Operation not supported.
However I decided to reflash my bios to
an earlier version and ... problem solved, so far. If there is someway I
can further things by supplying specifics
about what might have changed please let me know what sort of
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
Avi Kivity wrote:
On 08/03/2009 05:04 PM, Anthony Liguori wrote:
Actually, VT mandates that vmcalls can only be done from CPL=0.
That's exactly how I misremembered it. However the docs say
IF not in VMX operation
THEN #UD;
ELSIF in VMX non-root operation
THEN VM exit;
ELSIF
On 07/27/2009 03:23 AM, Jordan Justen wrote:
From: Jordan Justenjljus...@gmail.com
These changes are similar to my patches sent July 16, except they
now are based on Yang Sheng's recent changes to enable a new
ioctl for controlling the EPT identity mapping page location.
Applied, thanks.
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always
On 08/03/2009 06:14 PM, Michael S. Tsirkin wrote:
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
-
On 08/03/2009 05:55 PM, John wrote:
Hello,
This was initially a complaint about kvm-amd Operation not
supported. However I decided to reflash my bios to
an earlier version and ... problem solved, so far. If there is someway
I can further things by supplying specifics
about what might have
On 08/03/2009 06:04 PM, Anthony Liguori wrote:
So CPL 0 is only enforced on VMCALL from the hypervisor, not the
guest (tip: don't ask what VMCALL in the hypervisor means).
Ah, it's used to call SMM peer mode... awesome :-)
Now you'll never be able to sleep at night. Well I did try to warn
The argument to kernel space should be u64 rather than unsigned long.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 492dbc5..5fa89e8 100644
--- a/qemu-kvm-x86.c
Should be new ept_identity_map_addr rather than old macro.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
---
On Aug 3, 2009, Avi Kivity a...@redhat.com wrote:
On 07/31/2009 05:15 PM, Kai Zimmer wrote:
qemu-kvm -hda xyz.qcow2 -daemonize -net nic,model=virtio -net tap -k de -m
3584 -smp 2 -mem-path /hugepages -vnc :2
Any ideas what goes wrong here?
All three guests have the same MAC address,
Hi all!
I have a KVM VM that it has installed a MRTG on the network interface
and that it doesn't register more than 10 Mbps, seeming that per moments
it is saturated in this value.
Has KVM some bandwidth limitation of the virtualized network interfaces?
In such case, exists some way to increase
Avi Kivity wrote:
On 08/03/2009 04:47 PM, Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still
On Tuesday 04 August 2009 00:47:16 Marcelo Tosatti wrote:
On Mon, Aug 03, 2009 at 02:17:27PM +0800, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Why?
My fault in userspace...
--
regards
Yang, Sheng
Also fix a mistake of still using old macro rather than new variable().
Daniel Bareiro wrote:
Hi all!
I have a KVM VM that it has installed a MRTG on the network interface
and that it doesn't register more than 10 Mbps, seeming that per moments
it is saturated in this value.
Has KVM some bandwidth limitation of the virtualized network interfaces?
In such
On Mon, Aug 03, 2009 at 06:29:36PM +0300, Avi Kivity wrote:
On 08/03/2009 06:14 PM, Michael S. Tsirkin wrote:
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set,
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be as
simple as adding the below additions to kvm_setup_guest_memory in kvm-all.c
(and adding the necessary kernel changes of course)?
On Tuesday 28 July 2009 11:39:59 am Izik Eidus wrote:
This patch is not for inclusion
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be as
simple as adding the below additions to kvm_setup_guest_memory in kvm-all.c
qemu-kvm-0.x.x doesnt tell me much, but if it is the function that
register the memory than yes...
(I just remember
On Monday 03 August 2009 01:09:38 pm Izik Eidus wrote:
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be
as simple as adding the below additions to kvm_setup_guest_memory in
kvm-all.c
qemu-kvm-0.x.x doesnt tell me much, but if it is the function
Brian Jackson wrote:
On Monday 03 August 2009 01:09:38 pm Izik Eidus wrote:
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be
as simple as adding the below additions to kvm_setup_guest_memory in
kvm-all.c
qemu-kvm-0.x.x doesnt tell me
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed /dev/vmch*
This patchset introduces unattended install to autotest. This is a
first-pass implementation for reviewers, and actually we don't have
much else to say, except that we need to:
* Create unattended install files for all our supported os (that
will be a large task)
* Implement simple templating
This allows you to not specify the full path in the
config file, appends to the image dir.
Signed-off-by: David Huff dh...@redhat.com
---
client/tests/kvm/kvm_vm.py | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/kvm_vm.py
In order to resolve the question, 'how will the guest
operating system tell the host operating system that
the unattended install process finish', we took the
simple approach and created a simple socket communication
ack process: The test instantiates a server tcp socket
on port 12323, and waits
For the purpose of developing the test, 2 operating systems
were used, Fedora 11 and Windows XP 32 bit. This patch adds
the unattended install files for each OS:
* Fedora 11: Fedora-11.ks
* Win XP: winnt.bat and winxp32.sif
Attention: Actually those 2 files *should* be templates that
would
In order to make windows guests to tell the unattended install
server that the install process ended, a simple C++ program
using the winsock 2 API had to be developed. The program was
based on an MSDN article. Its usage is
finish.exe [host-ip]
The test expect this to be compiled under deps. This
In order to accomodate the unattended install test,
some changes had to be made:
* Now cd isos and md5 sum values don't belong only
to the step file install only
* introduced the needed variables for the unattended
install test
* Created 2 test sets, winxp_unattended and fc11_unattended.
I am
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
This patchset introduces unattended install to autotest. This is a
first-pass implementation for reviewers, and actually we don't have
much else to say, except that we need to:
* Create unattended install files for all our supported os
Hi Gregory.
On Monday, 03 August 2009 12:52:28 -0400,
Gregory Haskins wrote:
I have a KVM VM that it has installed a MRTG on the network
interface and that it doesn't register more than 10 Mbps, seeming
that per moments it is saturated in this value.
Has KVM some bandwidth limitation
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
In order to accomodate the unattended install test,
some changes had to be made:
* Now cd isos and md5 sum values don't belong only
to the step file install only
* introduced the needed variables for the unattended
install test
*
Bugs item #2823765, was opened at 2009-07-19 01:59
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2823765group_id=180599
Please note that this message will contain a full copy of the comment
The test code looks nice and simple. However, I don't think putting some
of the code in a class helps much (it doesn't hurt either).
What do you think about this alternative, replacing from 'watcher = ...':
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('', 12323))
Daniel Bareiro wrote:
Hi Gregory.
On Monday, 03 August 2009 12:52:28 -0400,
Gregory Haskins wrote:
I have a KVM VM that it has installed a MRTG on the network
interface and that it doesn't register more than 10 Mbps, seeming
that per moments it is saturated in this value.
Has KVM some
On Mon, Aug 03, 2009 at 02:37:29PM +0300, Dor Laor wrote:
On 08/03/2009 12:19 PM, Yolkfull Chow wrote:
On 06/30/2009 09:58 PM, Dor Laor wrote:
On 06/30/2009 02:11 PM, Yolkfull Chow wrote:
Signed-off-by: Yolkfull Chowyz...@redhat.com
---
client/tests/kvm/kvm.py | 1 +
Hi,
I am seeing a telnet failure in autotest to a win2k8 DC 64 bit guest.
I have tried some debugging and came to a conclusion that
read_nonblocking() is reading only 3 lines. let me first print the
output of manual login
# telnet -l Administrator 10.0.99.100 23
Trying 10.0.99.100...
Connected
Looks like there really are only 3 lines to read.
Telnet is printing those lines, not windows. It's just indicating
that it successfully connected. Windows is saying nothing.
This is a little weird, because:
- It can happen when the telnet server isn't running at all,
but it seemed to be
This patchset add guest debug support for BOOKE.
patch 1: fix current e500 broken
patch 2: guest debug definitions
patch 3: switch shadow/host debug register on guest enter/exit path
patch 4: guest debug support
patch 5: exitnr fixup in single step mode
[v2]
1. move code from 2.6.30 to current
Remove the broken trace.
Will get them cleanup in future.
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kvm/e500_tlb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index fb1e1dc..a344be6 100644
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm.h | 20
arch/powerpc/include/asm/kvm_host.h | 18 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h
So that we don't give any chance for host to trigger the debug event.
Also the debug ability in guest can be implemented based on this.
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kernel/asm-offsets.c |3 ++
arch/powerpc/kvm/booke_interrupts.S | 58
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm_ppc.h |5 ++
arch/powerpc/kvm/booke.c | 97 ++--
arch/powerpc/kvm/e500.c|8 ---
arch/powerpc/kvm/powerpc.c |2 +-
4 files changed, 99
As BOOKE doesn't have hardware support for virtualization,
hardware never know guest and host.
So when enable hardware single step for guest,
it cannot be disabled timely if guest want to exit.
Thus, we'll see that an single step interrupt happens at
the beginning of guest exit path.
Then we need
-Original Message-
From: Liu Yu-B13201
Sent: Monday, August 03, 2009 7:08 PM
To: kvm-ppc@vger.kernel.org
Cc: holl...@us.ibm.com; a...@redhat.com; Liu Yu-B13201
Subject: [PATCH 2/5] kvmppc guest debug definitions
Signed-off-by: Liu Yu yu@freescale.com
---
87 matches
Mail list logo
