Re: [PATCH 5/5] x86/shadow: l3table[] and gl3e[] are HVM only

2020-07-20 Thread Tim Deegan
At 10:55 +0200 on 20 Jul (1595242521), Jan Beulich wrote: > On 18.07.2020 20:20, Tim Deegan wrote: > > At 12:00 +0200 on 15 Jul (1594814409), Jan Beulich wrote: > >> ... by the very fact that they're 3-level specific, while PV always gets > >> run in 4-level mode. This requires adding some seemingl

Re: [PATCH 5/5] x86/shadow: l3table[] and gl3e[] are HVM only

2020-07-20 Thread Jan Beulich
On 18.07.2020 20:20, Tim Deegan wrote: > At 12:00 +0200 on 15 Jul (1594814409), Jan Beulich wrote: >> ... by the very fact that they're 3-level specific, while PV always gets >> run in 4-level mode. This requires adding some seemingly redundant >> #ifdef-s - some of them will be possible to drop ag

Re: [PATCH 5/5] x86/shadow: l3table[] and gl3e[] are HVM only

2020-07-18 Thread Tim Deegan
At 12:00 +0200 on 15 Jul (1594814409), Jan Beulich wrote: > ... by the very fact that they're 3-level specific, while PV always gets > run in 4-level mode. This requires adding some seemingly redundant > #ifdef-s - some of them will be possible to drop again once 2- and > 3-level guest code doesn't

[PATCH 5/5] x86/shadow: l3table[] and gl3e[] are HVM only

2020-07-15 Thread Jan Beulich
... by the very fact that they're 3-level specific, while PV always gets run in 4-level mode. This requires adding some seemingly redundant #ifdef-s - some of them will be possible to drop again once 2- and 3-level guest code doesn't get built anymore in !HVM configs, but I'm afraid there's still q