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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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