Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Ed White <edmund.h.white@intel.com>]

On 03/04/2015 03:06 PM, Tamas K Lengyel wrote:
>>>>>> Right. The key observation is that at any single point in time, a given
>>>>>> hardware thread can be fetching an instruction or reading data, but not
>>>>>> both.
>>>>>
>>>>> Fine, as long as an instruction reading itself isn't going to lead to
>>>>> a live lock.
>>>>>
>>>>
>>>> That's not how the hardware works. By the time you figure out that the
>>>> instruction you are executing reads memory, the instruction itself has
>>>> been fetched and decoded. That won't happen again during this execution.
>>>
>>> Can you explain?  If the instruction faults and is returned to,
>>> execution starts again, right?  So for an instruction that reads itself:
>>>
>>> - the fetch succeeds;
>>> - the read fails, and we fault;
>>> - the hypervisor switches from mapping MFN 1 (--x) to MFN 2 (r--);
>>> - the hypervisor returns to the guest.
>>>
>>> Are you relying on the icache/trace cache/whatever to restart
>>> the instruction from a cached value rather than fault immediately?
>>> (Because the hypervisor didn't flush the TLB when it changed the mapping)?
>>>
>>
>> Nope. I just typed before drinking enough coffee. That whole answer was bogus.
>>
>> Of course, if an instruction reads itself you can get a live lock using
>> these techniques, but it's a software-induced live lock and software can
>> avoid it. One way is compare the address being read with the instruction
>> pointer, and if they are on the same page emulate instead of switching p2m's.
>>
>> Ed
> 
> Hi Ed,
> we have been poking at this idea of achieving singlestepping through
> altp2m view-switching (which would be supported by the VMFUNC
> EPTP-switching) and the problem discussed above is not limited to
> instructions that perform data accesses on the same page where the
> instruction executing was fetched from. In order to achieve true
> single-stepping, the immediate next instruction should be causing an
> EPT violation.
> 
> Let's assume we trap an instruction that only performs data accesses
> on pages other than the one the instruction was fetched from. Since
> the instruction fetch is repeated after a failed data access due to
> EPT violation, the page containing the instruction has to be at least
> --x and the pages that will be touched by it rw- (or the proper
> combination or r-- and rw-) simultaneously in order to avoid getting
> into a live-lock. This results in all subsequent instruction fetches
> to succeed from the original page. Furthermore, as long as all such
> subsequent instructions keep accessing only the pages touched by the
> first instruction, we could end up missing a good chunk of code
> execution. Is there something we are missing here or is this a known
> limitation to the EPT-based singlestepping mechanism? Or is there
> something in the way VMFUNC is implemented that will avoid this
> limitation?
> 
> Thanks,
> Tamas
> 

If you truly need single-step, then there is no alternative to doing
that the traditional way using TF. What I was hinting at before (and
I seem to have offended you by doing so) is that if your only reason
for single-stepping is to revert a view switch, then depending on your
use-case the single-step may be avoidable. At the risk of offending
you again, I still can't talk about that in more detail.

Is there any chance you might reconsider your decision not to help
with toolstack support of the patch series? I'm still trying to find
an internal resource to do that work, but right now it's the biggest
risk I see to getting the series into 4.6.

Since this discussion has started up again, I should tell you that
after today I probably won't be able to post to the list until next
week.

Ed