Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Avi Kivity wrote: > >>>But does the fact KVM doesn't use TCG prevent KVM from running some > >>>x86 modes correctly? E.g. I gather 16-bit code is run by KVM using > >>>VM86 mode, which is not exactly correct. It would be nice to have KVM > >>>acceleration but also complete and correct emulation, by switching to > >>>TCG for those modes. > >>> > >>There is work in progress to make 16-bit emulation fully accurate. > > > >Ooh! I want my Windows 95 to run in KVM :-) > >I'm curious, how is this planned to work? > > > >I'm having trouble thinking of how to do it without software emulation > >at some stage. > > By emulating all instructions that can't be virtualized. Ah, I see (after much reading)... the idea is to finish the software emulator for real-mode instructions in the kernel, include floating point and 32-bit, and then to stop using VM86 altogether when emulating real-mode. VM86 might still be used to virtualize VM86 :-) Fortunately the set of instructions in real-mode is small (by x86 standards!), and listed in Intel's system architecture manual: "Instructions Supported in Real-Address Mode", plus x87 instructions and a few quasi-undocumented ones. Other instructions (MMX, SSE, etc.) cannot run in real mode, so a complete real-mode emulator is reasonably small. I was under the impression real-mode emulation needed to cover most of the x86 instruction set, which is large, but this is not required. Great! I'm looking forward to running Windows 95 and 3.11 under it :-) -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Avi Kivity wrote: Jamie Lokier wrote: But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. There is work in progress to make 16-bit emulation fully accurate. Ooh! I want my Windows 95 to run in KVM :-) I'm curious, how is this planned to work? I'm having trouble thinking of how to do it without software emulation at some stage. By emulating all instructions that can't be virtualized. Since TCG is not smp-safe, this is very problematic for smp guests. You would have to stop virtualization on all vcpus and start tcg on all of them. Performance would plummet. On the other hand, when running on a KVM-capable architecture combination, it is definitely possible to make TCG smp-safe because every guest atomic instruction has a corresponding host one. It's practically a 1:1 instruction mapping on x86, which doesn't have many atomic instructions. (Maybe harder on other archs). Maybe. It's simpler to fix kvm not to require this. I don't want kvm to be tied to qemu; when userspace tells kvm to run a vcpu, it means run the vcpu; not "run the vcpu unless there are some instructions you can't run for some undocumented reason". There are ways of mitigating the high mmio cost with kvm. For framebuffers, one can allow kvm direct access. For other mmio, there's the 'coalesced mmio' support which allows mmio to be batched when this does not affect emulation accuracy and latency. Don't you still have to trap for each MMIO in order to collect the batch, except for REP instructions? It's the traps which are expensive. Fortunately modern hardware tends to use DMA for data intensive things, and MMIO just to trigger DMA, and initialisation. In practice things work fine. 16-color modes are slow but only very old software was designed to work with them, so it expected the hardware to be slow. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Firstly: That doesn't make sense: why would you do an expensive TCG translation every time you hit the same code? After the first encounter, if the code page hasn't been modified, it should be a TB cache lookup to already translated code. Except that once you run under KVM again, you lose all dirty information and you have to invalidate all TBs. FWIW, a few years ago, we implemented this concept with QEMU and Xen. That's where my data is coming from. I'm guessing the cost of TB cache lookup is much closer to 3k than 300k cycles, maybe even lower... You're guessing and it doesn't matter anyway because the TB cache has to be invalidated. Secondly: In these cases, you can use a special fast translation (when it's not cached) which just copies the instructions 1:1 from the guest, simply converting the special instructions (MMIO, anything else needing it) to helper calls. That's possible because you know the host is ture architeccompatible with the guest, as it's running KVM. You can't copy 1:1 because the instructions aren't 1:1. Only trivial instructions that manipulate registers remain the same but even then, you have to do register renaming and on the x86 this probably means you'll have to spill some registers because you have so few. Any memory reference (mov, push, pop, etc.) must be translated to a different instruction because you don't have a virtual address that can be accessed directly so you need a hook to simulate a tlb miss. You can preserve atomicity if you try hard enough, but it certainly isn't a 1:1 translation in softmmu mode. If you also consider all the potential locking issues with SMP guests, I think it's pretty likely that there are few cases where dropping to TCG is going to be a net performance win. VMware claimed otherwise when Intel first brought out CPU support for virtualisation. That's just not true. The paper that you're most likely referencing was much more nuanced than that and the hardware has improved dramatically since then. SMP works fine if you map guest instructions 1:1 to host instructions with helper calls for special cases. Even atomics, load-locked sequences and complex weak memory ordering things would behave correctly. You can't translate 1:1 so your argument falls apart. Regards, Anthony Liguori Oops, I believe I just argued for keeping the TB cache and code translation but not using TCG :-) -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Anthony Liguori wrote: > Jamie Lokier wrote: > >Also, an earlier thread pointed out that loops doing a lot of MMIO are > >_slower_ with KVM than without - this manifested as very slow VGA > >output for some guests. Having KVM pass control to TCG for short runs > >of guest instructions which do MMIO, or other instructions which need > >to be emulated, would accelerate KVM in this respect. ... > An MMIO exit to userspace typically costs around 6k cycles. On the > other hand, a TB translation tends to average closer to 300k often times > reaching much higher. This with was with dyngen so TCG may be more or > less expensive. > > An in-kernel MMIO exit on the other hand will cost around 3k cycles. ... > To make up the cost of TCG translation for just one TB, you need to have > a tight loop of at least 50 iterations. Firstly: That doesn't make sense: why would you do an expensive TCG translation every time you hit the same code? After the first encounter, if the code page hasn't been modified, it should be a TB cache lookup to already translated code. I'm guessing the cost of TB cache lookup is much closer to 3k than 300k cycles, maybe even lower... Secondly: In these cases, you can use a special fast translation (when it's not cached) which just copies the instructions 1:1 from the guest, simply converting the special instructions (MMIO, anything else needing it) to helper calls. That's possible because you know the host is ture architeccompatible with the guest, as it's running KVM. > If you also consider all the potential locking issues with SMP guests, I > think it's pretty likely that there are few cases where dropping to TCG > is going to be a net performance win. VMware claimed otherwise when Intel first brought out CPU support for virtualisation. SMP works fine if you map guest instructions 1:1 to host instructions with helper calls for special cases. Even atomics, load-locked sequences and complex weak memory ordering things would behave correctly. Oops, I believe I just argued for keeping the TB cache and code translation but not using TCG :-) -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. Note, the devil is in the details here. An MMIO exit to userspace typically costs around 6k cycles. On the other hand, a TB translation tends to average closer to 300k often times reaching much higher. This with was with dyngen so TCG may be more or less expensive. An in-kernel MMIO exit on the other hand will cost around 3k cycles. MMIO coalescing is pretty efficient because it effectively reduces the cost of a exit by half. To make up the cost of TCG translation for just one TB, you need to have a tight loop of at least 50 iterations. We can handle rep instructions with a single exit in KVM so this needs to be an actual MMIO loop, not a rep loop. If you also consider all the potential locking issues with SMP guests, I think it's pretty likely that there are few cases where dropping to TCG is going to be a net performance win. Regards, Anthony Liguori -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Anthony Liguori wrote: Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG present is not a problem when using KVM on x86. x86 already has TCG host and target support and it's quite convenient to be able to disable/enable KVM and compare it to TCG when debugging. I agree with removing/isolating the dependency on TCG, and there are good reasons for it. But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. That's just a limitation of Intel VT. AMD SVM runs 16-bit code natively. We're slowly improving our in-kernel emulator so eventually we'll be able to emulate 16-bit mode in the kernel. Running 16-bit code in TCG is something that has been considered. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. It falls apart for SMP guests. TCG does not preserve atomicity of memory instructions so you could never have an SMP VCPU running on bare metal while TCG is running. There is a rather large initial cost for building the TBs too so in practice, there are few areas that benefit from this sort of hand off. The VGA optimization actually addresses this problem in a much nicer way. KVM also supports MMIO batching which we'll eventually merge that covers the remaining cases pretty well. Regards, Anthony Liguori -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
2008/11/14 Anthony Liguori <[EMAIL PROTECTED]>: > The issue is not disabling TCG at runtime. That's easy enough. The issue > is that TCG doesn't exist (and probably won't ever exist) for certain > architectures like ia64 and s390. Being forced to build with TCG support > makes having QEMU + KVM not possible on these platforms even though they > both support KVM. I mean either compile-time or run-time: assuming that each QEMUAccel implementation is a bunch of files + a struct with pointers in the common code, it should make turning on/off each emulator easy. Cheers -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Avi Kivity wrote: > Jamie Lokier wrote: > >But does the fact KVM doesn't use TCG prevent KVM from running some > >x86 modes correctly? E.g. I gather 16-bit code is run by KVM using > >VM86 mode, which is not exactly correct. It would be nice to have KVM > >acceleration but also complete and correct emulation, by switching to > >TCG for those modes. > > There is work in progress to make 16-bit emulation fully accurate. Ooh! I want my Windows 95 to run in KVM :-) I'm curious, how is this planned to work? I'm having trouble thinking of how to do it without software emulation at some stage. > >Also, an earlier thread pointed out that loops doing a lot of MMIO are > >_slower_ with KVM than without - this manifested as very slow VGA > >output for some guests. Having KVM pass control to TCG for short runs > >of guest instructions which do MMIO, or other instructions which need > >to be emulated, would accelerate KVM in this respect. (I think VMware does something like this, btw). > Since TCG is not smp-safe, this is very problematic for smp guests. You > would have to stop virtualization on all vcpus and start tcg on all of > them. Performance would plummet. On the other hand, when running on a KVM-capable architecture combination, it is definitely possible to make TCG smp-safe because every guest atomic instruction has a corresponding host one. It's practically a 1:1 instruction mapping on x86, which doesn't have many atomic instructions. (Maybe harder on other archs). > There are ways of mitigating the high mmio cost with kvm. For > framebuffers, one can allow kvm direct access. For other mmio, there's > the 'coalesced mmio' support which allows mmio to be batched when this > does not affect emulation accuracy and latency. Don't you still have to trap for each MMIO in order to collect the batch, except for REP instructions? It's the traps which are expensive. Fortunately modern hardware tends to use DMA for data intensive things, and MMIO just to trigger DMA, and initialisation. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. There is work in progress to make 16-bit emulation fully accurate. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. Since TCG is not smp-safe, this is very problematic for smp guests. You would have to stop virtualization on all vcpus and start tcg on all of them. Performance would plummet. There are ways of mitigating the high mmio cost with kvm. For framebuffers, one can allow kvm direct access. For other mmio, there's the 'coalesced mmio' support which allows mmio to be batched when this does not affect emulation accuracy and latency. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Anthony Liguori wrote: > Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG > present is not a problem when using KVM on x86. x86 already has TCG host and > target support and it's quite convenient to be able to disable/enable KVM and > compare it to TCG when debugging. I agree with removing/isolating the dependency on TCG, and there are good reasons for it. But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
andrzej zaborowski wrote: 2008/11/13 Anthony Liguori <[EMAIL PROTECTED]>: andrzej zaborowski wrote: Is this going a bit in the opposite direction to where QEMUAccel is going? What Fabrice suggests seems to be like QEMUAccel, with TCG treated as another accelerator. QEMUAccel is a bit orthogonal to what I'm talking about. There is already KVM support in QEMU today and I'm merely looking to restructure existing code so that I can build a version of QEMU that has no TCG support, only KVM support. TCG is too intimately woven into QEMU right now. You could think of this perhaps as a precursor to making TCG more of an "accelerator" than it is today. Ah, I agree with your patch, I was only commenting on the idea of *-kvm/ targets. I see something like QEMUAccel as a way to turn on and off the cpu emulators (TCG, kvm, kqemu). The issue is not disabling TCG at runtime. That's easy enough. The issue is that TCG doesn't exist (and probably won't ever exist) for certain architectures like ia64 and s390. Being forced to build with TCG support makes having QEMU + KVM not possible on these platforms even though they both support KVM. The idea behind a -kvm target is to be able to use QEMU + KVM on these architectures in a clean way. We could also build qemu-system-s390 and just exclude TCG but from a naming perspective, it makes sense to be qemu-kvm because there can only be a single KVM executable for any given platform. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
2008/11/13 Anthony Liguori <[EMAIL PROTECTED]>: > andrzej zaborowski wrote: >> Is this going a bit in the opposite direction to where QEMUAccel is >> going? What Fabrice suggests seems to be like QEMUAccel, with TCG >> treated as another accelerator. >> > > QEMUAccel is a bit orthogonal to what I'm talking about. There is already > KVM support in QEMU today and I'm merely looking to restructure existing > code so that I can build a version of QEMU that has no TCG support, only KVM > support. TCG is too intimately woven into QEMU right now. You could think > of this perhaps as a precursor to making TCG more of an "accelerator" than > it is today. Ah, I agree with your patch, I was only commenting on the idea of *-kvm/ targets. I see something like QEMUAccel as a way to turn on and off the cpu emulators (TCG, kvm, kqemu). Ofcourse, kqemu depends on a fallback emulator - currently TCG - I guess it could be possible to run kqemu with kvm as the fall back and not compile in TCG (even if not a very useful configuration). > > But wrt QEMUAccel and KVM, there are 5 places in QEMU where there is KVM > specific code. > > One is cpu-exec.c to invoke the kvm exec routine instead of TCG. kqemu has > something similar. Unfortunately, kqemu relies on some state that's only > available in cpu-exec.c so we can't make this a single function pointer > invocation without major surgery on cpu-exec. > > One is vl.c to initialize KVM support. kqemu doesn't need this. > > One is exec.c, to hook cpu_register_physical_memory. kqemu does this too so > it could conceivably be a hook. > > Another one is monitor.c to implement 'info kvm'. Not really a place for a > hook. Ideally we could register the monitor callback from kvm-all.c when we > initialize KVM. > > Finally, there is a hook in hw/acpi.c to disable SMM support when using KVM. > This is KVM specific because KVM doesn't support SMM. kqemu uses TCG to > run SMM code. > > Since there is only one shared hook ATM, I don't think something like > QEMUAccel is all that useful for KVM. On the other hand, there are 42 > places that are kqemu specific. I think kqemu could be refactored to > eliminate most of these. > > kqemu relies on TCG so you can't really decouple them from each other. > >> BTW It would be great if before merging a change like this you >> review/merge the patches submitted to the list that might touch the >> same area so as not to break them (such as Jan Kiszka's >> single-stepping/watchpoint fixes). >> > > Yeah, I will make sure to. Many thanks for that. Regards -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
andrzej zaborowski wrote: Is this going a bit in the opposite direction to where QEMUAccel is going? What Fabrice suggests seems to be like QEMUAccel, with TCG treated as another accelerator. QEMUAccel is a bit orthogonal to what I'm talking about. There is already KVM support in QEMU today and I'm merely looking to restructure existing code so that I can build a version of QEMU that has no TCG support, only KVM support. TCG is too intimately woven into QEMU right now. You could think of this perhaps as a precursor to making TCG more of an "accelerator" than it is today. But wrt QEMUAccel and KVM, there are 5 places in QEMU where there is KVM specific code. One is cpu-exec.c to invoke the kvm exec routine instead of TCG. kqemu has something similar. Unfortunately, kqemu relies on some state that's only available in cpu-exec.c so we can't make this a single function pointer invocation without major surgery on cpu-exec. One is vl.c to initialize KVM support. kqemu doesn't need this. One is exec.c, to hook cpu_register_physical_memory. kqemu does this too so it could conceivably be a hook. Another one is monitor.c to implement 'info kvm'. Not really a place for a hook. Ideally we could register the monitor callback from kvm-all.c when we initialize KVM. Finally, there is a hook in hw/acpi.c to disable SMM support when using KVM. This is KVM specific because KVM doesn't support SMM. kqemu uses TCG to run SMM code. Since there is only one shared hook ATM, I don't think something like QEMUAccel is all that useful for KVM. On the other hand, there are 42 places that are kqemu specific. I think kqemu could be refactored to eliminate most of these. kqemu relies on TCG so you can't really decouple them from each other. BTW It would be great if before merging a change like this you review/merge the patches submitted to the list that might touch the same area so as not to break them (such as Jan Kiszka's single-stepping/watchpoint fixes). Yeah, I will make sure to. Regards, Anthony Liguori Cheers -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
2008/11/12 Anthony Liguori <[EMAIL PROTECTED]>: > Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG > present is not a problem when using KVM on x86. x86 already has TCG host and > target support and it's quite convenient to be able to disable/enable KVM and > compare it to TCG when debugging. > > KVM also supports architectures that do not have TCG host and target support > such as ia64, s390, and PPC[1]. For these architectures, TCG is an inhibitor > for upstream inclusion. > > TCG is pretty well isolated in QEMU so building these targets without TCG > should be easy enough. This breaks down in exec.c though. There is a lot of > TCG specific code in exec.c, but also a lot of code that KVM needs. > > This patch moves the non-TCG specific bits of exec.c into a separate file, > exec-all.c. This makes it relatively easy to build QEMU without TCG support. > More patches will come to complete this work but the exec.c bits are probably > 95% of what is needed. > > The remaining bits are some general cleanups where layering has been violated > and the introduction of a new -kvm subtarget, similar to -softmmu or > -linux-user. Is this going a bit in the opposite direction to where QEMUAccel is going? What Fabrice suggests seems to be like QEMUAccel, with TCG treated as another accelerator. BTW It would be great if before merging a change like this you review/merge the patches submitted to the list that might touch the same area so as not to break them (such as Jan Kiszka's single-stepping/watchpoint fixes). Cheers -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Fabrice Bellard wrote: I suggest to go even further: there should be a way in QEMU to define CPUs which do not rely on the dynamic translator and this choice should be doable at runtime (i.e. not with a bunch of #ifdefs as you may do it). This way you could not only plug KVM CPUs without having the equivalent TCG one, but also CPUs from other sources (i.e. the x86 interpreter of malc, or the cycle accurate PTLsim x86 emulator). Today, we do this with KVM support without any ifdefs (what's in SVN right now). We leave the TCG and the KVM state in CPUState, and then just use the appropriate cpu_exec() loop to run depending on the CPU type. We could go a step further and split out the core x86 CPU state from CPUX86State, and then introduce a CPUTCGState and CPUKVMState that both include CPUX86State but that seems like a lot of churn for little gain (KVM just adds two more fields to CPUX86State). What I'm trying to do with this patch, is make it possible to get rid of the TCG code altogether for targets that only support KVM and not TCG (ia64, s390, etc). How I'll eventually get rid of it is not with #ifdefs, but by just not compiling in all the TCG code, cpu-exec.c, exec.c and instead just compiling in a kvm-exec.c or something like that. Regards, Anthony Liguori Fabrice. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Anthony Liguori wrote: > Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG > present is not a problem when using KVM on x86. x86 already has TCG host and > target support and it's quite convenient to be able to disable/enable KVM and > compare it to TCG when debugging. > > KVM also supports architectures that do not have TCG host and target support > such as ia64, s390, and PPC[1]. For these architectures, TCG is an inhibitor > for upstream inclusion. > > TCG is pretty well isolated in QEMU so building these targets without TCG > should be easy enough. This breaks down in exec.c though. There is a lot of > TCG specific code in exec.c, but also a lot of code that KVM needs. > > This patch moves the non-TCG specific bits of exec.c into a separate file, > exec-all.c. This makes it relatively easy to build QEMU without TCG support. > More patches will come to complete this work but the exec.c bits are probably > 95% of what is needed. > > The remaining bits are some general cleanups where layering has been violated > and the introduction of a new -kvm subtarget, similar to -softmmu or > -linux-user. This target will not have TCG support and only support KVM. > However, before going down that path, I wanted to see if anyone objected to > this > bit of the cleanup. > > Any objections? I suggest to go even further: there should be a way in QEMU to define CPUs which do not rely on the dynamic translator and this choice should be doable at runtime (i.e. not with a bunch of #ifdefs as you may do it). This way you could not only plug KVM CPUs without having the equivalent TCG one, but also CPUs from other sources (i.e. the x86 interpreter of malc, or the cycle accurate PTLsim x86 emulator). Fabrice. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
