On 23.11.2023 12:01, Roger Pau Monné wrote: > On Thu, Nov 23, 2023 at 11:50:41AM +0100, Jan Beulich wrote: >> On 23.11.2023 11:47, Roger Pau Monné wrote: >>> On Thu, Nov 23, 2023 at 11:25:34AM +0100, Jan Beulich wrote: >>>> Avoid logging all-identical messages for every vCPU, but make sure to >>>> log unusual events like the vector differing from vCPU 0's (note that >>>> the respective condition also makes sure vCPU 0 itself will have the >>>> vector setting logged), or it changing after it was once set. (Arguably >>>> a downside is that some vCPU not having its vector set would no longer >>>> be recognizable from the logs. But I think that's tolerable as >>>> sufficiently unlikely outside of people actively fiddling with related >>>> code.) >>> >>> Maybe we could consider printing unconditionally for debug builds? >> >> Indeed I was considering that, but it's primarily debug builds where the >> unnecessary redundancy is annoying me. (After all I work with debug builds >> much more than with release ones.) > > I did find the message useful when doing guest bringup in the past, in > order to know the guest was correctly setting up the vector callbacks. > > I guess there are other ways to figure that out, or the message could > be added when people is doing bringup themselves. > > I find the save/restore messages during domain create much more > unhelpful and annoying that this.
Yeah, these too are ugly. But going through this save/restore cycle when starting a guest is supposed to go away anyway, according to Andrew. Plus the primary annoyance here is for PVH Dom0 with vCPU count not restricted, and there's no save/restore involved there. The typical HVM guest, otoh, wouldn't have as many vCPU-s ... Jan
