On 8/28/18 11:13 AM, Jan Beulich wrote:
On 28.08.18 at 10:04, wrote:
>> On 27/08/18 15:08, Jan Beulich wrote:
>> On 27.08.18 at 15:47, wrote:
On 8/27/18 4:17 PM, Jan Beulich wrote:
On 27.08.18 at 15:02, wrote:
>> This should be architecturally correct as it is exclusiv
>>> On 28.08.18 at 10:04, wrote:
> On 27/08/18 15:08, Jan Beulich wrote:
> On 27.08.18 at 15:47, wrote:
>>> On 8/27/18 4:17 PM, Jan Beulich wrote:
>>> On 27.08.18 at 15:02, wrote:
> This should be architecturally correct as it is exclusively derived from
> information provided by
On 27/08/18 15:08, Jan Beulich wrote:
On 27.08.18 at 15:47, wrote:
>> On 8/27/18 4:17 PM, Jan Beulich wrote:
>> On 27.08.18 at 15:02, wrote:
This should be architecturally correct as it is exclusively derived from
information provided by the VMExit, and won't cause dirty bits t
>>> On 27.08.18 at 15:47, wrote:
> On 8/27/18 4:17 PM, Jan Beulich wrote:
> On 27.08.18 at 15:02, wrote:
>>> This should be architecturally correct as it is exclusively derived from
>>> information provided by the VMExit, and won't cause dirty bits to be
>>> written in cases where the hardwar
>>> On 27.08.18 at 15:24, wrote:
> On 8/27/18 4:02 PM, Andrew Cooper wrote:
>> On 27/08/18 13:53, Razvan Cojocaru wrote:
>>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
On 27/08/18 13:12, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request wa
On 8/27/18 4:17 PM, Jan Beulich wrote:
On 27.08.18 at 15:02, wrote:
>> This should be architecturally correct as it is exclusively derived from
>> information provided by the VMExit, and won't cause dirty bits to be
>> written in cases where the hardware wouldn't have written them
>> (specula
On 8/27/18 4:02 PM, Andrew Cooper wrote:
> On 27/08/18 13:53, Razvan Cojocaru wrote:
>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>>> On 27/08/18 13:12, Jan Beulich wrote:
>> For NPT, isn't there an error code bit telling you whether the
>> request was a user or "system" one? If not, some ch
>>> On 27.08.18 at 15:02, wrote:
> On 27/08/18 13:53, Razvan Cojocaru wrote:
>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>>> On 27/08/18 13:12, Jan Beulich wrote:
>> For NPT, isn't there an error code bit telling you whether the
>> request was a user or "system" one? If not, some cheating
On 27/08/18 13:53, Razvan Cojocaru wrote:
> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>> On 27/08/18 13:12, Jan Beulich wrote:
> For NPT, isn't there an error code bit telling you whether the
> request was a user or "system" one? If not, some cheating
> would be needed (derive from CPL,
On 8/27/18 3:37 PM, Andrew Cooper wrote:
> On 27/08/18 13:12, Jan Beulich wrote:
For NPT, isn't there an error code bit telling you whether the
request was a user or "system" one? If not, some cheating
would be needed (derive from CPL, accepting that e.g.
descriptor table access
On 27/08/18 13:12, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request was a user or "system" one? If not, some cheating
>>> would be needed (derive from CPL, accepting that e.g.
>>> descriptor table accesses would get mis-attributed), but
>>> that's st
On 8/27/18 3:12 PM, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request was a user or "system" one? If not, some cheating
>>> would be needed (derive from CPL, accepting that e.g.
>>> descriptor table accesses would get mis-attributed), but
>>> that's s
>>> On 27.08.18 at 13:24, wrote:
> On 8/27/18 12:11 PM, Jan Beulich wrote:
> On 24.08.18 at 20:47, wrote:
>>> 619 /* EPT violation qualifications definitions */
>>> 620 typedef union ept_qual {
>>> 621 unsigned long raw;
>>> 622 struct {
>>> 623 bool read:1, write:1, fetch:1,
On 8/27/18 12:11 PM, Jan Beulich wrote:
On 24.08.18 at 20:47, wrote:
>> 619 /* EPT violation qualifications definitions */
>> 620 typedef union ept_qual {
>> 621 unsigned long raw;
>> 622 struct {
>> 623 bool read:1, write:1, fetch:1,
>> 624 eff_read:1, eff_write:1
>>> On 24.08.18 at 20:47, wrote:
> On 8/24/18 8:49 PM, Andrew Cooper wrote:
>> On 24/08/18 15:11, Alexandru Isaila wrote:
>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>> index 03a864156..b01194d 100644
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/m
On 8/24/18 8:49 PM, Andrew Cooper wrote:
> On 24/08/18 15:11, Alexandru Isaila wrote:
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index 03a864156..b01194d 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -212,7 +212,20 @@ bo
On 24/08/18 15:11, Alexandru Isaila wrote:
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 03a864156..b01194d 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -212,7 +212,20 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned lo
The original version of the patch emulated the current instruction
(which, as a side-effect, emulated the page-walk as well), however we
need finer-grained control. We want to emulate the page-walk, but still
get an EPT violation event if the current instruction would trigger one.
This patch perfor
18 matches
Mail list logo
