On Tuesday 02 February 2010 19:26:55 Ian Campbell wrote:
> On Tue, 2010-02-02 at 08:16 +0000, Sheng Yang wrote:
> > +static hvm_hypercall_t *hvm_hypercall_hybrid64_table[NR_hypercalls] =
> > {
> > + [ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op,
> > + [ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t
> > *)hvm_grant_table_op,
> > + HYPERCALL(xen_version),
> > + HYPERCALL(console_io),
> > + HYPERCALL(vcpu_op),
> > + HYPERCALL(sched_op),
> > + HYPERCALL(event_channel_op),
> > + HYPERCALL(hvm_op),
> > +};
>
> Why not just expand the exiting hvm hypercall table to incorporate these
> new hypercalls?
I am just afraid the normal HVM guest called these hypercalls would result in
some chaos, so add a limitation(for hybrid only) here. (I admit it didn't much
improve the security for a malicious guest...)
>
> In fact, why is hybrid mode considered a separate mode by the hypervisor
> at all? Shouldn't it just be an extension to regular HVM mode which
> guests may choose to use? This seems like it would eliminate a bunch of
> the random conditionals.
There is still something different from normal HVM guest. For example, to use
PV timer, we should clean the tsc offset in HVM domain; and for event
delivery, we would use predefined VIRQ rather than emulated IOAPIC/APIC. These
code are exclusive, we need them wrapped with flag(which we called "hybrid").
The word "mode" here may be is inaccuracy, a "extension" should be more
proper. I would change the phrase next time.
>
> Have you verified that all of the operations you are making available
> are safe to be called from (hybrid)hvm mode?
You mean malicious guest attack? Sorry, I haven't try it yet...
--
regards
Yang, Sheng
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home