On Monday 12 February 2007 18:29, Steven Rostedt wrote:
> Host always mapped:
>
> Since the virtual address space is very large, it would be much
> simpler to just keep the Host always mapped in the Guests
> address space. So the Guest will be more like a process here.
> So instead of just mapping the HV in both the Guest and Host as
> a hypervisor_blob, the entire Host will continually remain
> mapped. This simplifies things tremendously.
How do you protect the host from the guest kernel then?
Segment limits as used by i386 lguest won't work.
[there is one way I know of but it has some drawbacks
and wouldn't work with a fully mapped linux kernel host]
The Xen method is to run guest kernel and guest guest both
at ring 3 with different address spaces. Or you can use VT/SVM.
> The VCPU descriptor:
>
> This will hold function pointers for system calls and fault
> handlers.
These would be better just mapped to a known address?
> System Calls:
>
> On all system calls (host users or guest users) the VCPU field
> of the PDA will be checked. If it is NULL, nothing different
> will happen than what the host already does today (see why it's
> better to have the field in the PDA). But if it is not NULL it
> will jump to the system_call function pointer of the VCPU
> structure to perform the guest operations.
What is the point of this? Just to optimize hypercalls or something else?
Do you expect hypercalls from user space to be common?
> We really want to get involved, and we want to do it right, right from
> the start. As mentioned earlier, we are new to the workings of lguest,
> and want to help out on the x86_64 front, even while it's still being
> developed on the i386 front. We feel that because of the lack of
> limitations that x86_64 gives, the work on the x86_64 will be a large
> fork from what lguest does on i386.
It will be certainly quite different, except for the drivers.
-Andi
