On 17/11/15 18:49, Andy Lutomirski wrote: > On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" <boris.ostrov...@oracle.com> wrote: >> On 11/16/2015 04:55 PM, H. Peter Anvin wrote: >>> On 11/16/15 12:22, Borislav Petkov wrote: >>>> Huh, so what's wrong with a jump: >>>> >>>> jmp 1f >>>> swapgs >>>> 1: >>>> >>> What is the point of that jump? >>> >>>>> If it would make you feel better, it could be X86_BUG_XENPV :-p >>>> That doesn't matter - I just don't want to open the flood gates on >>>> pseudo feature bits. >>>> >>>> hpa, what do you think? >>> Pseudo feature bits are fine, we already have plenty of them. They make >>> sense as they let us reuse a lot of infrastructure. >> >> >> So how about something like this? And then I think we can remove >> usergs_sysret32 and irq_enable_sysexit pv ops completely as noone will use >> them (lguest doesn't set them) >> > Looks good to me. Does Xen have any sysexit/sysret32 equivalent to > return to 32-bit user mode? If so, it could be worth trying to wire > it up by patching the jz instead of the test instruction.
>From the guests point of view, there is only hypercall_iret. > > Also, I'd prefer X86_FEATURE_XENPV. IMO "PV" means too many things to > too many people. I agree - PV on its own is too generic. An alternative might be X86_FEATURE_XEN_PV_GUEST which is very clear an unambiguous, although rather longer. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
