>>> On 13.02.17 at 16:33, wrote:
> On 13/02/17 15:30, Jan Beulich wrote:
> On 13.02.17 at 16:26, wrote:
>>> On 13/02/17 15:19, Jan Beulich wrote:
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus.
> Introduce a
> new define a
On 13/02/17 15:30, Jan Beulich wrote:
On 13.02.17 at 16:26, wrote:
>> On 13/02/17 15:19, Jan Beulich wrote:
>> On 13.02.17 at 15:32, wrote:
Xen's choice of the MSR_STAR value is constant across all pcpus.
Introduce a
new define and use it to avoid the opencoding in
>>> On 13.02.17 at 16:26, wrote:
> On 13/02/17 15:19, Jan Beulich wrote:
> On 13.02.17 at 15:32, wrote:
>>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce
>>> a
>>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>>> and restore_rest_
On 13/02/17 15:19, Jan Beulich wrote:
On 13.02.17 at 15:32, wrote:
>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>> and restore_rest_processor_state().
>>
>> Despite Intel hardwa
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
>
> Despite Intel hardware having an MSR_CSTAR register, nothing ac
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Despite Intel hardware having an MSR_CSTAR register, nothing actually uses it
as the SYSCALL instruction ra
