On Fri, Mar 05, 2021 at 11:56:33AM +0100, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
> > uint64_t *msr_content)
> >
On 05.03.2021 11:56, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> const struct domain *d =
On 04.03.2021 15:47, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
On 05.03.2021 10:15, Roger Pau Monné wrote:
> On Fri, Mar 05, 2021 at 12:06:19AM +, Andrew Cooper wrote:
>> On 04/03/2021 14:47, Roger Pau Monne wrote:
>>> From a release PoV the biggest risk would be breaking some of the
>>> existing MSR functionality. I think that's a necessary risk in order
On 04.03.2021 18:43, Roger Pau Monné wrote:
> One option we could go for is making this behavior depend on Kconfig:
> enable strict MSR policy for debug builds and fallback to the
> 'relaxed' one for non-debug builds. That might get us some more data,
> but again I fear most people out there will
On Fri, Mar 05, 2021 at 12:06:19AM +, Andrew Cooper wrote:
> On 04/03/2021 14:47, Roger Pau Monne wrote:
> > Introduce an option to allow selecting a less strict behaviour for
> > rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> > commit 84e848fd7a162f669 accesses to MSRs
On Thu, Mar 04, 2021 at 11:28:16PM +, Andrew Cooper wrote:
> On 04/03/2021 23:09, Boris Ostrovsky wrote:
> > On 3/4/21 9:47 AM, Roger Pau Monne wrote:
> >> Introduce an option to allow selecting a less strict behaviour for
> >> rdmsr accesses targeting a MSR not explicitly handled by Xen.
On 04/03/2021 14:47, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
On 04/03/2021 23:09, Boris Ostrovsky wrote:
> On 3/4/21 9:47 AM, Roger Pau Monne wrote:
>> Introduce an option to allow selecting a less strict behaviour for
>> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
>> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled
On 3/4/21 9:47 AM, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> One option we could go for is making this behavior depend on Kconfig:
> enable strict MSR policy for debug builds and fallback to the
> 'relaxed' one for non-debug builds. That might
On Thu, Mar 04, 2021 at 05:13:15PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
> for HVM relaxed rdmsr behavior"):
> > On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> > > The guest could be stopped with xl shutdown and
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> > The guest could be stopped with xl shutdown and then recrated with xl
> > create, from the config file. I don't think
On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
> for HVM relaxed rdmsr behavior"):
> > On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> > > I think it's almost as bad to have guests which
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> > I think it's almost as bad to have guests which can be migrated in,
> > but which then cannot reboot.
>
> Ups, yes,
On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 for-4.15] x86/msr: introduce an option for
> HVM relaxed rdmsr behavior"):
> > Introduce an option to allow selecting a less strict behaviour for
> > rdmsr accesses targeting a MSR not explicitly
Roger Pau Monne writes ("[PATCH v2 for-4.15] x86/msr: introduce an option for
HVM relaxed rdmsr behavior"):
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not
Introduce an option to allow selecting a less strict behaviour for
rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
Xen result in the injection of a #GP to the guest. This is a behavior
change since previously a
18 matches
Mail list logo
