On 05.07.2019 16:40, Andrew Cooper wrote:
> For now, I'm tempted to go with an answer of "it doesn't need to be the
> compat GDT".
Which is fine with me.
> This is a rabbit hole I really don't have time to follow atm.
Fully understood. From the very beginning I was only after some commit
messag
On 05/07/2019 14:56, Jan Beulich wrote:
> On 05.07.2019 15:36, Andrew Cooper wrote:
>> On 05/07/2019 11:00, Jan Beulich wrote:
>>> On 04.07.2019 19:57, Andrew Cooper wrote:
Also, it should now be very obvious to people that Xen's current GDT
handling
for non-PV vcpus is a recipe sub
On 05.07.2019 15:36, Andrew Cooper wrote:
> On 05/07/2019 11:00, Jan Beulich wrote:
>> On 04.07.2019 19:57, Andrew Cooper wrote:
>>> Also, it should now be very obvious to people that Xen's current GDT
>>> handling
>>> for non-PV vcpus is a recipe subtle bugs, if we ever manage to execute a
>>> s
On 05/07/2019 11:00, Jan Beulich wrote:
> On 04.07.2019 19:57, Andrew Cooper wrote:
>> write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
>> with (mfn + i) is wrong, because of PDX compression. The context switch path
>> only functions correctly because NR_RESERVED_GDT_PAGE
On 04.07.2019 19:57, Andrew Cooper wrote:
> write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
> with (mfn + i) is wrong, because of PDX compression. The context switch path
> only functions correctly because NR_RESERVED_GDT_PAGES is 1.
Whether this is a (latent) bug depen
On 04.07.19 19:57, Andrew Cooper wrote:
write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
with (mfn + i) is wrong, because of PDX compression. The context switch path
only functions correctly because NR_RESERVED_GDT_PAGES is 1.
As this is exceedingly unlikely to change
