On Thu, Feb 4, 2016 at 5:27 AM, Razvan Cojocaru
wrote:
> Currently, after receiving a vm_event reply requesting emulation,
> the actual emulation is triggered in p2m_mem_access_check(),
> which means that we're waiting for the page fault to occur again
> before emulating. Aside from the performan
> >> The logic makes sense, so Acked-by: Andrew Cooper
> >> for the x86-related nature, but it would be
> >> nice to have a review from Tamas for the vm_event side of things.
> >
> > Thanks! Of course. Hopefully Tamas will like this, based on a
> > conversation we've had a few days ago here.
>
Ye
On 02/04/2016 02:52 PM, Razvan Cojocaru wrote:
> On 02/04/2016 02:36 PM, Andrew Cooper wrote:
>> On 04/02/16 12:27, Razvan Cojocaru wrote:
>>> Currently, after receiving a vm_event reply requesting emulation,
>>> the actual emulation is triggered in p2m_mem_access_check(),
>>> which means that we'r
On 02/04/2016 02:36 PM, Andrew Cooper wrote:
> On 04/02/16 12:27, Razvan Cojocaru wrote:
>> Currently, after receiving a vm_event reply requesting emulation,
>> the actual emulation is triggered in p2m_mem_access_check(),
>> which means that we're waiting for the page fault to occur again
>> before
On 04/02/16 12:27, Razvan Cojocaru wrote:
> Currently, after receiving a vm_event reply requesting emulation,
> the actual emulation is triggered in p2m_mem_access_check(),
> which means that we're waiting for the page fault to occur again
> before emulating.
Presumably this means that we re-enter
Currently, after receiving a vm_event reply requesting emulation,
the actual emulation is triggered in p2m_mem_access_check(),
which means that we're waiting for the page fault to occur again
before emulating. Aside from the performance impact, this
complicates the code since between hvm_do_resume(
