| Message ID | 930254a6-d0c8-4910-982a-bfd227187240@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/spec-ctrl: IPBP improvements | expand |
On 25/01/2023 3:24 pm, Jan Beulich wrote: > Versions of the two final patches were submitted standalone earlier > on. The series here tries to carry out a suggestion from Andrew, > which the two of us have been discussing. Then said previously posted > patches are re-based on top, utilizing the new functionality. > > 1: spec-ctrl: add logic to issue IBPB on exit to guest > 2: spec-ctrl: defer context-switch IBPB until guest entry > 3: limit issuing of IBPB during context switch > 4: PV: issue branch prediction barrier when switching 64-bit guest to kernel mode In the subject, you mean IBPB. I think all the individual patches are fine. Do you have an implementation of VMASST_TYPE_mode_switch_no_ibpb for Linux yet? The thing I'd like to avoid is that we commit this perf it to Xen, without lining Linux up to be able to skip it. ~Andrew
On 25.01.2023 18:49, Andrew Cooper wrote: > On 25/01/2023 3:24 pm, Jan Beulich wrote: >> Versions of the two final patches were submitted standalone earlier >> on. The series here tries to carry out a suggestion from Andrew, >> which the two of us have been discussing. Then said previously posted >> patches are re-based on top, utilizing the new functionality. >> >> 1: spec-ctrl: add logic to issue IBPB on exit to guest >> 2: spec-ctrl: defer context-switch IBPB until guest entry >> 3: limit issuing of IBPB during context switch >> 4: PV: issue branch prediction barrier when switching 64-bit guest to kernel mode > > In the subject, you mean IBPB. I think all the individual patches are fine. Yes, I did notice the typo immediately after sending. > Do you have an implementation of VMASST_TYPE_mode_switch_no_ibpb for > Linux yet? The thing I'd like to avoid is that we commit this perf it > to Xen, without lining Linux up to be able to skip it. No, I don't. I haven't even looked at where invoking this might be best placed. Also I have to admit that it's not really clear to me what the criteria are going to be for Linux to disable this, and whether perhaps finer grained control might be needed (i.e. to turn it on/off dynamically under certain conditions). In any event this concern is only related to patch 4; I'd appreciate if at least the earlier three patches wouldn't be blocked on there being something on the Linux side. (In fact patch 3 ends up [still] being entirely independent of the rest of the rework, unlike I think you were expecting it to be.) Jan