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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Thu, Mar 5, 2015 at 12:41 AM, Ed White <edmund.h.white@xxxxxxxxx> wrote:
> 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.

I see, that is indeed different than actual singlestepping - which was
also implied by the Zero-footprint slides to be possible via VMFUNC.
Maybe not calling singlestepping in the future would avoid confusion.
Sorry if I came of as offended, I understand its not your decision
what Intel decides to share. What you started to contribute is already
very valuable and appreciated. I just see too many subsystems already
within Xen without documentation that were built to support
proprietary systems where the original authors refuse to share
information on how to actually use it (mem sharing for example). For
people who are outside that loop it's frustrating to reverse engineer
the usecase from the source.

>
> 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.

My comment regarding hesitation in committing toolstack code that is
suboptimal still stands. Many people look at these as reference
implementations, thus a faulty or suboptimal contribution here can
have highly uncompetitive effects. IMHO that's not how open source
should work. Of course if that's not the case for at least some
usecases I would be happy to help with those.

> 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

Thanks,
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel