Hi Marc, Paolo,
On 6/1/20 7:21 PM, Paolo Bonzini wrote:
On 31/05/20 14:44, Marc Zyngier wrote:
Is there an ARM-approved way to reuse the S2 fault syndromes to detect
async page faults?
It would mean being able to set an ESR_EL2 register value into ESR_EL1,
and there is nothing in the archite
On 31/05/20 14:44, Marc Zyngier wrote:
>>
>> Is there an ARM-approved way to reuse the S2 fault syndromes to detect
>> async page faults?
>
> It would mean being able to set an ESR_EL2 register value into ESR_EL1,
> and there is nothing in the architecture that would allow that,
I understand that
On 2020-05-29 12:11, Paolo Bonzini wrote:
On 29/05/20 11:41, Marc Zyngier wrote:
For x86 the advantage is that the processor can take care of raising
the
stage2 page fault in the guest, so it's faster.
I think there might be too much overhead if the page can be populated
quickly by host. F
On 29/05/20 11:41, Marc Zyngier wrote:
>>>
>>>
>>> For x86 the advantage is that the processor can take care of raising the
>>> stage2 page fault in the guest, so it's faster.
>>>
>> I think there might be too much overhead if the page can be populated
>> quickly by host. For example, it's fast to
On 2020-05-29 00:02, Gavin Shan wrote:
Hi Paolo,
On 5/28/20 8:48 PM, Paolo Bonzini wrote:
On 28/05/20 08:14, Gavin Shan wrote:
- for x86 we're also thinking of initiating the page fault from the
exception handler, rather than doing so from the hypervisor before
injecting the exception. If ARM
Hi Paolo,
On 5/28/20 8:48 PM, Paolo Bonzini wrote:
On 28/05/20 08:14, Gavin Shan wrote:
- for x86 we're also thinking of initiating the page fault from the
exception handler, rather than doing so from the hypervisor before
injecting the exception. If ARM leads the way here, we would do our
bes
On 28/05/20 09:03, Marc Zyngier wrote:
> The current state of the architecture doesn't seem to leave much leeway in
> terms of SW creativity here. You just can't allocate your own ISS encoding
> without risking a clash with future revisions of the architecture.
> It isn't even clear whether the val
On 28/05/20 08:14, Gavin Shan wrote:
>> - for x86 we're also thinking of initiating the page fault from the
>> exception handler, rather than doing so from the hypervisor before
>> injecting the exception. If ARM leads the way here, we would do our
>> best to share code when x86 does the same.
>
Hi Paolo,
On 5/27/20 4:48 PM, Paolo Bonzini wrote:
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:
- the page ready signal can be done as an interrupt, rather than an
exception. This is because "page ready" can be han
On 2020-05-28 07:14, Gavin Shan wrote:
Hi Paolo,
On 5/27/20 4:48 PM, Paolo Bonzini wrote:
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:
- the page ready signal can be done as an interrupt, rather than an
exception.
Hi Gavin,
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:
- the page ready signal can be done as an interrupt, rather than an
exception. This is because "page ready" can be handled asynchronously,
in contrast to "page n
On Fri, May 08, 2020 at 01:29:19PM +1000, Gavin Shan wrote:
> This supports asynchronous page fault for the guest. The design is
> similar to what x86 has: on receiving a PAGE_NOT_PRESENT signal from
> the host, the current task is either rescheduled or put into power
> saving mode. The task will b
This supports asynchronous page fault for the guest. The design is
similar to what x86 has: on receiving a PAGE_NOT_PRESENT signal from
the host, the current task is either rescheduled or put into power
saving mode. The task will be waken up when PAGE_READY signal is
received. The PAGE_READY signal
13 matches
Mail list logo
