On Thu, Aug 22, 2019 at 06:38:41PM +0200, Paolo Bonzini wrote:
> On 22/08/19 15:17, Yang Weijiang wrote:
> > On Tue, Aug 20, 2019 at 09:44:35PM +0800, Yang Weijiang wrote:
> >> On Mon, Aug 19, 2019 at 05:04:23PM +0200, Paolo Bonzini wrote:
> >>> fast_page_fault should never trigger an SPP userspace
On 22/08/19 15:17, Yang Weijiang wrote:
> On Tue, Aug 20, 2019 at 09:44:35PM +0800, Yang Weijiang wrote:
>> On Mon, Aug 19, 2019 at 05:04:23PM +0200, Paolo Bonzini wrote:
>>> fast_page_fault should never trigger an SPP userspace exit on its own,
>>> all the SPP handling should go through handle_spp
On Tue, Aug 20, 2019 at 09:44:35PM +0800, Yang Weijiang wrote:
> On Mon, Aug 19, 2019 at 05:04:23PM +0200, Paolo Bonzini wrote:
> > On 19/08/19 16:43, Paolo Bonzini wrote:
> > >> +/*
> > >> + * Record write protect fault caused by
> > >> +
On Mon, Aug 19, 2019 at 05:04:23PM +0200, Paolo Bonzini wrote:
> On 19/08/19 16:43, Paolo Bonzini wrote:
> >> + /*
> >> + * Record write protect fault caused by
> >> + * Sub-page Protection, let VMI decide
> >> + * the next step
On 19/08/19 16:43, Paolo Bonzini wrote:
>> +/*
>> + * Record write protect fault caused by
>> + * Sub-page Protection, let VMI decide
>> + * the next step.
>> + */
>> +if (spte &
On 14/08/19 09:04, Yang Weijiang wrote:
> + /*
> + * Record write protect fault caused by
> + * Sub-page Protection, let VMI decide
> + * the next step.
> + */
> + if (spte &
If write to subpage is not allowed, EPT violation is generated,
it's propagated to QEMU or VMI to handle.
If the target page is SPP protected, however SPPT missing is
encoutered while traversing with gfn, vmexit is generated so
that KVM can handle the issue. Any SPPT misconfig will be
propagated t
7 matches
Mail list logo