Re: [kvm-devel] [ToDo] Real Mode Support
On Wed, 2008-02-06 at 08:33 +0100, Guillaume Thouvenin wrote: Hello, I read on the kvmwiki/TODO that there is a work in progress for extending x86 emulator to support more instructions in real mode and for changing the execution loop to call the emulator for real mode. As I'm interested to work on this part I'd like to know what was already done. cool! I'd like to have more information about how the execution loop need to be changed. Currently we enter/leave real mode through a call to enter_rmode()/enter_pmode(). The function sets a variable arch.rmode.active and also sets the bit X86_EFLAGS_VM of GUEST_RFLAGS. That means that we are using the VM mode to virtualize the real mode. I know that in virtual mode some instructions can not be used as they are in full real mode (that would have been too easy). So these instructions generate a protection fault and need to be emulated. So we handle this kind of exception in handle_exception() and we call the x86 emulator. From the emulator we read the eflags (kvm_x86_ops-get_rflags(vcpu)) and we can know if we are in real mode or not. It's the current scheme, right? My question is why the execution loop needs to be changed here. I mean isn't it possible to just extend x86 emulator to support more instructions in real mode? I think that I'm missing something here so any help, hint, advice, link are welcome. Best Regards, i am not expert for the emulator area, but as far as i remember: virtual 8086 have some checks related to segments (the big mode problem), it mean that for some addresses it wont be able to execute anything, you will just get vmexit right away, therefor you need a full functional emulator that will handle everything there. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
On Wed, 06 Feb 2008 10:52:54 +0200 Izik Eidus [EMAIL PROTECTED] wrote: i am not expert for the emulator area, but as far as i remember: virtual 8086 have some checks related to segments (the big mode problem), it mean that for some addresses it wont be able to execute anything, you will just get vmexit right away, therefor you need a full functional emulator that will handle everything there. Oh thanks, I remember now. The problem seems to be with the descriptor cache register. In protected mode and also in virtual mode the descriptor cache register is fully loaded each time a segment register is loaded. It's not the case in real mode. So every program that uses this feature (the big real mode) will not work under vm8086. Thus we need to remove the usage of the virtual mode and instead we need to fully emulate the real mode in order to be big real mode compliant. Does somebody know if there are already some patches or some other stuff about big real mode support? Regards, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
On Wed, 2008-02-06 at 13:07 +0100, Guillaume Thouvenin wrote: On Wed, 06 Feb 2008 10:52:54 +0200 Izik Eidus [EMAIL PROTECTED] wrote: i am not expert for the emulator area, but as far as i remember: virtual 8086 have some checks related to segments (the big mode problem), it mean that for some addresses it wont be able to execute anything, you will just get vmexit right away, therefor you need a full functional emulator that will handle everything there. Oh thanks, I remember now. The problem seems to be with the descriptor cache register. In protected mode and also in virtual mode the descriptor cache register is fully loaded each time a segment register is loaded. It's not the case in real mode. So every program that uses this feature (the big real mode) will not work under vm8086. Thus we need to remove the usage of the virtual mode and instead we need to fully emulate the real mode in order to be big real mode compliant. Does somebody know if there are already some patches or some other stuff about big real mode support? i think that there used to be talks about this before long time ago, i dont know what the state is (i hard to belive anyone is working on it right now), but to be sure we will have to wait to avi. Regards, Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH] Add print for PowerPC qemu for failed DCR read/writes
Yeah, rate-limiting makes sense. Maybe we could take it one step further
and only print the warning the first time a particular unemulated DCR is
accessed.
I also agree about the captalization. :)
--
Hollis Blanchard
IBM Linux Technology Center
On Wed, 2008-02-06 at 12:25 +0100, Christian Ehrhardt wrote:
hi Jerone,
I think this is good for debugging to find unsupported hardware, but it
should not be enabled by default (you could get a printf storm if a guest
workload does stupid things). Maybe qemu has some debug/verbose options you
can use.
And additionally it would be useful for the dcr_write patch to print the
value it tried to write.
I also don't know if we really need that caps-locked in the output.
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1202249136 21600
# Node ID 4bbbf98ebf05ef77dbb68e2131b3bc0764767c99
# Parent f8cab6a29bf3f34f1cbf4d1e6d7bd21809fd4184
Add print for PowerPC qemu for failed DCR read/writes
This patch adds a print to notify of failed reads and rights. Currently
we will still ignore them (until development is fully done). But this makes
them easier to spot.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/qemu/qemu-kvm-powerpc.c b/qemu/qemu-kvm-powerpc.c
--- a/qemu/qemu-kvm-powerpc.c
+++ b/qemu/qemu-kvm-powerpc.c
@@ -178,13 +178,17 @@ int handle_powerpc_dcr_read(int vcpu, ui
int handle_powerpc_dcr_read(int vcpu, uint32_t dcrn, uint32_t *data)
{
CPUState *env = cpu_single_env;
-ppc_dcr_read(env-dcr_env, dcrn, data);
+if (ppc_dcr_read(env-dcr_env, dcrn, data) 0)
+printf(DCR FAILED on READ at 0x%x\n, dcrn);
+
return 0; /* XXX ignore failed DCR ops */
}
int handle_powerpc_dcr_write(int vcpu, uint32_t dcrn, uint32_t data)
{
CPUState *env = cpu_single_env;
-ppc_dcr_write(env-dcr_env, dcrn, data);
+if (ppc_dcr_write(env-dcr_env, dcrn, data) 0)
+printf(DCR FAILED on WRITE at 0x%x\n, dcrn);
just a suggestion
printf(%s - failed writing 0x%x @ 0x%x\n, dcrn, data);
+
return 0; /* XXX ignore failed DCR ops */
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-ppc-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
On Wed, 2008-02-06 at 11:32 -0600, Anthony Liguori wrote: Guillaume Thouvenin wrote: Hello, I read on the kvmwiki/TODO that there is a work in progress for extending x86 emulator to support more instructions in real mode and for changing the execution loop to call the emulator for real mode. Yes, Nitin has done some work in this area. As I'm interested to work on this part I'd like to know what was already done. I'd like to have more information about how the execution loop need to be changed. Currently we enter/leave real mode through a call to enter_rmode()/enter_pmode(). The function sets a variable arch.rmode.active and also sets the bit X86_EFLAGS_VM of GUEST_RFLAGS. That means that we are using the VM mode to virtualize the real mode. I know that in virtual mode some instructions can not be used as they are in full real mode (that would have been too easy). So these instructions generate a protection fault and need to be emulated. So we handle this kind of exception in handle_exception() and we call the x86 emulator. From the emulator we read the eflags (kvm_x86_ops-get_rflags(vcpu)) and we can know if we are in real mode or not. It's the current scheme, right? Sort of. Right now we put the guest into vm86 mode and use that to execute real mode code. There are a number of problems with using vm86 (some due to VT restrictions on vm86). The biggest problem is Big Real Mode. In real mode, the x86 uses segmentation only. Normally, the segment limits are setup to be 0x and since the translation for segment mode is 16-bit segment register * 16, you can address 2^20 work of address space. However, if you switch to protected mode, you can setup the GDT to have 4G segments. If you then switch back to real mode, you can use 32-bit address overrides to access the full 32-bit address space in 16-bit mode. vm86 does not support this trick though. To further complicate matters, there are certain gotcha's when using vm86 with VT that are less easy to detect. So what we would like to do, is instead of setting up vm86 mode for the guest to execute real mode, use x86_emulate() to just emulate the code. This means that we wouldn't be using the vmlaunch instruction when in real mode and instead would be doing an x86_emulate() loop. and for the matter of fact there are not too many instructions that needed to be emulated in oreder to make it work as that the vm86 instructions are very limited anyway (15.1.3 in the intel manual list them) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Guest memory usage
Dietmar Maurer wrote: Hi Anthony, The problem is that memory always grows, even after rebooting the VM. When you start a VM, none of the memory for that VM has been reserved by Linux regardless of what you specify in the '-m' parameter. Instead, as the guest starts to access memory, Linux begins to allocate memory for the guest. free()'ing memory in the guest, rebooting the system, or anything else that you might thing should reduce memory consumption within the guest is meaningless to KVM. One a KVM guest has accessed memory, that memory is permanently allocated. There is, of course, an exception. If the host system is low on memory, then Linux will request that KVM remove memory from the guest. Again, this has nothing to do with what's going on in the guest, instead it has to do with what's going on in the host. The Linux host is acting to balance out memory in the most appropriate way to maximize performance. The guest will get as much memory as it needs until the host system starts getting low on memory. If you want to know what much of the memory the guest is using, you need to ask the guest to tell you that. Regards, Anthony Liguori The VSZ/RSS is correct. What you're seeing is probably a mix of two things. In the absence of MMU notifiers, not all Sorry for asking stupid questions: Why are they absent? Isn't there a way to track memory usage? There are 'info tlb' and 'info mem' commands - isn't it possible to construct better memory usage statistics whith that info? - Dietmar - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Fix to kvm_arch_vcpu_ioctl_set_sregs so that set_cr0 works properly
On Wed, Feb 06, 2008 at 11:02:35AM +, Paul Knowles wrote: mmu_reset_needed |= vcpu-arch.cr0 != sregs-cr0; - vcpu-arch.cr0 = sregs-cr0; kvm_x86_ops-set_cr0(vcpu, sregs-cr0); Why should this fix anything? The vcpu-arch.cr0 is also set in kvm_x86_ops-set_cr0() aka vmx_set_cr0() and its not touched on the path to it? Btw, I think its very likely that you set an invalid guest state with your set_sregs ioctl (e.g. an impossible hardware register state). Starting a guest in PAE mode is basically working because otherwise live migration of PAE guests won't work. Joerg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ToDo] Real Mode Support
I am still holding to few patches for big real mode. After rebase I will push those patches. Thanks Regards, Nitin Linux Open Source Technology Center, Intel Corporation The Mind is like a parachute; it works much better when it's open. -Original Message- From: [EMAIL PROTECTED] [mailto:kvm-devel- [EMAIL PROTECTED] On Behalf Of Guillaume Thouvenin Sent: Wednesday, February 06, 2008 4:07 AM To: Izik Eidus Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] [ToDo] Real Mode Support On Wed, 06 Feb 2008 10:52:54 +0200 Izik Eidus [EMAIL PROTECTED] wrote: i am not expert for the emulator area, but as far as i remember: virtual 8086 have some checks related to segments (the big mode problem), it mean that for some addresses it wont be able to execute anything, you will just get vmexit right away, therefor you need a full functional emulator that will handle everything there. Oh thanks, I remember now. The problem seems to be with the descriptor cache register. In protected mode and also in virtual mode the descriptor cache register is fully loaded each time a segment register is loaded. It's not the case in real mode. So every program that uses this feature (the big real mode) will not work under vm8086. Thus we need to remove the usage of the virtual mode and instead we need to fully emulate the real mode in order to be big real mode compliant. Does somebody know if there are already some patches or some other stuff about big real mode support? Regards, Guillaume --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
