Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: ... >> Yeah, that's close. Though I would have done the same for the other side of >> the if's too. >> (Still evaluating which mode is actually more useful for us). > > For Linux guests, there should be no reason to use ignore_msrs. Linux > is pretty resilient to "missing" MSRs (especially because they are already > ignored if the kernel is compiled with CONFIG_PARAVIRT=y!). The option is > really more for Windows, because it doesn't have anything like CONFIG_PARAVIRT > and because drivers are sometimes less vetted (and sometimes do RDMSR > themselves for whatever reason). In general we try to look at beta versions > of Windows and add any required MSRs well before the final release date, > but if you're using old kernels you might be stuck with ignore_msrs. > > IOW, if there was a really common reason to use ignore_msrs it would be > the default. ;) > >> Paolo, would you prefer this, or the other approach you already ack'd ? > > I think I prefer the other, because vcpu_debug is not ratelimited. > If the guest can trigger a printk it should always be ratelimited. Agree with rate limiting, but making this the default for everything doesn't sound right IMO, especially for ignore_msrs=1. vcpu_unimpl is already rate limited. Or is this change specifically to suppress messages on ignore_msrs=1 ? > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html