Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/03/2018 10:22, Jan Beulich wrote:
>>>> On 13.03.18 at 10:48, <jgross@xxxxxxxx> wrote:
>> On 13/03/18 10:35, Jan Beulich wrote:
>>>>>> On 13.03.18 at 10:27, <jgross@xxxxxxxx> wrote:
>>>> On 13/03/18 09:07, Jan Beulich wrote:
>>>>>>>> On 12.03.18 at 14:10, <jgross@xxxxxxxx> wrote:
>>>>>> BTW: are you already working on rebasing your XPTI speed up series to
>>>>>> current staging? I'd like my series to use your series as a base unless
>>>>>> you are telling me you won't be able to resend your series soon.
>>>>> Coming back to my reply here yesterday - then again I'm a little
>>>>> reluctant to send out a new version that has no changes other
>>>>> than being re-based, when there were no comments by Andrew
>>>>> on most of the remaining patches yet (and in the one case
>>>>> where there were comments, I'm afraid I continue to disagree,
>>>>> but I'll see about moving that patch last in the series).
>>>> In order to move forward, would you prefer me to base my patches on
>>>> current staging and put your patches on top of my series later? I just
>>>> don't want to rebase my series on a moving target...
>>> Well, I'm similarly not intending to re-base onto a series still under
>>> development / review. That's really the bad thing with deadlines:
>>> If we didn't freeze the tree at a given time, but at the point where
>>> previously agreed features and other non-bug-fix changes have
>>> landed, we wouldn't have such an ordering problem right now (or
>>> to be precise the ordering issue would still be there, but neither
>>> of us would be at risk of their changes not making it).
>> Understandable.
>>
>> Could you then please repost at least patch 3? It has been approved
>> by Andrew and just needs the formal R-b: after rebasing.
> Well, the thing with that patch is that from what I've been able
> to tell so far its re-basing will consist of dropping it, moving its
> sole remaining hunk (the altinstruction_nop assembler macro)
> into what has been patch 4. None of the uses of the macro in
> patch 3 should be needed anymore after Andrew's changes.
> Or actually I think the macro won't be needed as a standalone
> one anymore at all, as there's only a single place where it's
> used, and hence it would likely better be folded into there (the
> ALTERNATIVE_NOP one).

I'm sorry - I realise I'm very behind on reviews atm.  If you've got the
series rebased, then it will be easier to review this version than the
old version.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel