On 02/08/17 01:52, Andy Lutomirski wrote:
> On Tue, Aug 1, 2017 at 4:38 PM, Andrew Cooper
> wrote:
>> On 01/08/2017 20:45, Andy Lutomirski wrote:
>>> Also, IMO it would be nice to fully finish the job. Remaining steps are:
>>>
>>> 1. Unsuck the SYSCALL entries on Xen PV.
>>> 2. Unsuck the SYENTE
On 01/08/17 21:45, Andy Lutomirski wrote:
> On Tue, Aug 1, 2017 at 3:39 AM, Juergen Gross wrote:
>> When running as Xen pv-guest the exception frame on the stack contains
>> %r11 and %rcx additional to the other data pushed by the processor.
>>
>> Instead of having a paravirt op being called for e
On Tue, Aug 1, 2017 at 4:38 PM, Andrew Cooper wrote:
> On 01/08/2017 20:45, Andy Lutomirski wrote:
>> Also, IMO it would be nice to fully finish the job. Remaining steps are:
>>
>> 1. Unsuck the SYSCALL entries on Xen PV.
>> 2. Unsuck the SYENTER entry on Xen PV.
>> 3. Make a xen_nmi that's actua
On 01/08/2017 20:45, Andy Lutomirski wrote:
> Also, IMO it would be nice to fully finish the job. Remaining steps are:
>
> 1. Unsuck the SYSCALL entries on Xen PV.
> 2. Unsuck the SYENTER entry on Xen PV.
> 3. Make a xen_nmi that's actually correct (should be trivial)
>
> #1 is here:
>
> https://g
On Tue, Aug 1, 2017 at 3:39 AM, Juergen Gross wrote:
> When running as Xen pv-guest the exception frame on the stack contains
> %r11 and %rcx additional to the other data pushed by the processor.
>
> Instead of having a paravirt op being called for each exception type
> prepend the Xen specific co
When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.
Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just u
