Fabrice Bellard wrote:> As something like VMI is expected to be supported soon by QEMU, I have a > small question: does the virtualization API you are defining supports > that the guest kernel code can be executed in ring 3 ? >It certainly supports running the kernel in ring 1 or 2. The kernel uses the test CS.rpl != 3 to distinguish between kernel and user modes, and we're not proposing changing that.> In QEMU for example, the guest kernel code can be executed either by the > dynamic translator (in this case CS.rpl = 0 and SS.rpl = 0) or by the > kqemu kernel module (in this case CS.rpl = 3 and SS.rpl = 3). So a good > behaviour would be to ignore the rpl field of both CS and SS in kernel mode. >I think that would be a more widespread change than the ones we're proposing, but perhaps I'm overlooking something. J
Hi, As something like VMI is expected to be supported soon by QEMU, I have a small question: does the virtualization API you are defining supports that the guest kernel code can be executed in ring 3 ? In QEMU for example, the guest kernel code can be executed either by the dynamic translator (in this case CS.rpl = 0 and SS.rpl = 0) or by the kqemu kernel module (in this case CS.rpl = 3 and SS.rpl = 3). So a good behaviour would be to ignore the rpl field of both CS and SS in kernel mode. Regards, Fabrice.
Fabrice Bellard wrote:> Hi, > > As something like VMI is expected to be supported soon by QEMU, I have a > small question: does the virtualization API you are defining supports > that the guest kernel code can be executed in ring 3 ? > > In QEMU for example, the guest kernel code can be executed either by the > dynamic translator (in this case CS.rpl = 0 and SS.rpl = 0) or by the > kqemu kernel module (in this case CS.rpl = 3 and SS.rpl = 3). So a good > behaviour would be to ignore the rpl field of both CS and SS in kernel mode. >This requires a state tracking variable visible to the kernel, either directly, or abstracted via a function call, to answer, "did the previous interrupt context come from user mode?". That requires either changing the stack exception frame, or maintaining a parallel context stack, as well as adding a new paravirt-op, was_user_mode(u32 stack). This seems rather heavyweight, and without careful design, could possibly change the machine architecture such that the kernel can no longer run properly on native hardware. It is required, however, for x86_64 kernels, which will execute kernel code in ring 3. Things are a bit easier on x86_64 because of interrupt stacks. Definitely something to think about now, but I don't imagine it will be very possible to do on 32-bit without negatively impacting the critical path during return from kernel code. Zach
On Mon, 2006-07-31 at 15:33 -0400, Fabrice Bellard wrote:> Hi, > > As something like VMI is expected to be supported soon by QEMU, I have a > small question: does the virtualization API you are defining supports > that the guest kernel code can be executed in ring 3 ? > > In QEMU for example, the guest kernel code can be executed either by the > dynamic translator (in this case CS.rpl = 0 and SS.rpl = 0) or by the > kqemu kernel module (in this case CS.rpl = 3 and SS.rpl = 3). So a good > behaviour would be to ignore the rpl field of both CS and SS in kernel mode.Hi Fabrice, As most kernel developers consider non-GPL modules to be illegal, I would oppose altering a single line of kernel code to support such a module, as that would seem to be complicit. If QVM86 (or a compliant kqemu) ever gets into mainline, we can certainly do the mods then... Sorry if this disappoints, Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law