[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> From: Yu, Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx] > Sent: Thursday, April 14, 2016 5:57 PM > >>>>> And with all three bits now possibly being clear, aren't we risking the > >>>>> entries to be mis-treated as not-present ones? > >>>> > >>>> Hah. You got me. Thanks! :) > >>>> Now I realized it would be difficult if we wanna to emulate the read > >>>> operations for HVM. According to Intel mannual, entry->r is to be > >>>> cleared, so should entry->w if we do not want ept misconfig. And > >>>> with both read and write permissions being forbidden, entry->x can be > >>>> set only on processors with EXECUTE_ONLY capability. > >>>> To avoid any entry to be mis-treated as not-present. We have several > >>>> solutions: > >>>> a> do not support the read emulation for now - we have no such usage > >>>> case; > >>>> b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - > >>>> a bit weird to me. > >>>> Which one do you prefer? or any other suggestions? > >>> > >>> That question would also need to be asked to others who had > >>> suggested supporting both. I'd be fine with a, but I also don't view > >>> b as too awkward. > >> > >> According to Intel mannual, an entry is regarded as not present, if > >> bit0:2 is 0. So adding a p2m type check in is_epte_present() means we > >> will change its semantics, if this is acceptable(with no hurt to > >> hypervisor). I'd prefer option b> > > > > Perhaps time for the VMX maintainers to chime in - such a change is > > acceptable > > only if it doesn't result in changed hardware behavior. I can't think of > > any such off > > the top of my head, but this really should be confirmed by the maintainers > > before > > deciding to go such a route. > > > > Thanks, Jan. :) > Jun & Kevin, any suggestions? > I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |