On 11/17/2015 02:37 PM, Boris Ostrovsky wrote:
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
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.
We ca
On Tue, Nov 17, 2015 at 11:29 AM, Andrew Cooper
wrote:
> On 17/11/15 19:16, Andy Lutomirski wrote:
>> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
>> wrote:
>>> On 17/11/15 18:49, Andy Lutomirski wrote:
On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
wrote:
> On 11/16/2015 04:55 PM,
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
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.
We can actually make patching a little bit more effic
On 17/11/15 19:16, Andy Lutomirski wrote:
> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
> wrote:
>> On 17/11/15 18:49, Andy Lutomirski wrote:
>>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>>> wrote:
On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
> On 11/16/15 12:22, Borislav Petkov
On Tue, Nov 17, 2015 at 11:16:11AM -0800, Andy Lutomirski wrote:
> Works for me, too, although seeing "xen_pv_host" in the Linux cpu
> features would be very strange indeed :)
That feature would be, of course, *not* in /proc/cpuinfo.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails wh
On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
wrote:
> On 17/11/15 18:49, Andy Lutomirski wrote:
>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>> 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:
On 17/11/15 18:49, Andy Lutomirski wrote:
> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" 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:
>>>
On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" 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 i
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 do
On 11/16/2015 09:04 PM, Andy Lutomirski wrote:
> On Mon, Nov 16, 2015 at 1:03 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote:
>>> On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky
>>> wrote:
On 11/16/2015 03:22 PM, Borislav Petkov wrot
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 o
On Mon, Nov 16, 2015 at 1:03 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote:
>> On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky
>> wrote:
>> > On 11/16/2015 03:22 PM, Borislav Petkov wrote:
>> >>
>> >> On Mon, Nov 16, 2015 at 12:11:11PM -0800,
On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote:
> (In fact, I'm slowly working on removing KVM_GUEST's dependency on
> PARAVIRT.)
Good! The hope that we'll be able to remove paravirt one day is != 0
again.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you repl
On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky
wrote:
> On 11/16/2015 03:22 PM, Borislav Petkov wrote:
>>
>> On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote:
>>
>>> Are there really multiple feature bits for this stuff? I'd like to
>>> imagine that the entry code is all either
On 11/16/2015 03:22 PM, Borislav Petkov wrote:
On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote:
Are there really multiple feature bits for this stuff? I'd like to
imagine that the entry code is all either Xen PV or native/PVH/PVHVM
-- i.e. I assumed that PVH works like native f
On 11/16/2015 02:03 PM, Andy Lutomirski wrote:
It's still a waste of effort, though. Also, I'd eventually like the
number of places in Xen code in which rsp/esp is invalid to be exactly
zero, and this approach makes this harder or even impossible.
That's what PVH is going to do.
Does PVH h
On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov wrote:
> > On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote:
> >
> >> ...
> >> The reader surely doesn't remember that this isn't guaranteed to be a
> >> swapgs instr
On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov wrote:
> On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote:
>
>> ...
>> The reader surely doesn't remember that this isn't guaranteed to be a
>> swapgs instruction on native. Using:
>>
>> ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV
>>
On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote:
> ...
> The reader surely doesn't remember that this isn't guaranteed to be a
> swapgs instruction on native. Using:
>
> ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV
>
> would be safer (it would get rid of the SWAPGS_UNSAFE_STACK mes
On Mon, Nov 16, 2015 at 8:25 AM, Boris Ostrovsky
wrote:
> On 11/15/2015 01:02 PM, Andy Lutomirski wrote:
>>
>> On Nov 13, 2015 5:23 PM, "Boris Ostrovsky"
>> wrote:
>>>
>>>
>>>
>>> On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote
On 11/15/2015 01:02 PM, Andy Lutomirski wrote:
On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" wrote:
On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: R
On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" wrote:
>
>
>
> On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
>>
>> On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
>> wrote:
>>>
>>> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
>>> ("x86/entry/32: Re-implement SYSENTER usin
On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no lon
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs)
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
it's not pt_regs).
We need to adjust it so that subsequent xen_iret can use it.
25 matches
Mail list logo
