On 06/06/2025 15:23, Roger Pau Monné wrote: [...] >> >> Since this is meant to be a workaround, I wonder if it makes more sense >> to flip the setting (`xenpci_bar_wb`) and make it 0 by default? > > I originally didn't want to go that route, because while it's true > that the default MTRR type is set to WB, and so any memory not covered > by a MTRR range will default to that memory type I got the impression > this was inferring too much. > > Overall my intention would be for inverting the default long term, and > libxl setting build_info->u.hvm.xenpci_bar_uc = false by default, > which then makes all the naming nicer IMO. > >> It also >> simplifies the logic for both hvmloader and the consumer (no need for >> double negatives). > > I don't think there are double negatives? That would happen if the > variable was named xenpci_bar_no_uc or similar?
It's because from the flag consumer's viewpoint, I saw the flag `xenpci_bar_uc` as rather "xenpci_bar_dont_apply_wb_workaround`. But if the intention is to eventually make it default then the naming is OK for me. > > Thanks, Roger. Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
