[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][v2] Hybrid extension support in Xen
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |