2015-03-12 17:17-0400, Bandan Das:
> Joel Schopp writes:
> > @@ -2968,29 +2964,10 @@ static int cr_interception(struct vcpu_svm *svm)
> > kvm_queue_exception(&svm->vcpu, UD_VECTOR);
> > return 1;
> > }
> > - } else { /* mov from cr */
> > -
2015-03-16 11:16-0500, Joel Schopp:
> On 03/12/2015 04:20 PM, Radim Krčmář wrote:
> > 2015-03-12 15:17-0500, Joel Schopp:
> >> There isn't really a valid reason for kvm to intercept cr* reads
> >> on svm hardware. The current kvm code just ends up returning
> >> the register
> > There is no need t
On 03/12/2015 04:20 PM, Radim Krčmář wrote:
> 2015-03-12 15:17-0500, Joel Schopp:
>> There isn't really a valid reason for kvm to intercept cr* reads
>> on svm hardware. The current kvm code just ends up returning
>> the register
> There is no need to intercept CR* if the value that the guest sh
2015-03-12 15:17-0500, Joel Schopp:
> There isn't really a valid reason for kvm to intercept cr* reads
> on svm hardware. The current kvm code just ends up returning
> the register
There is no need to intercept CR* if the value that the guest should see
is equal to what we set there, but that is
Joel Schopp writes:
> There isn't really a valid reason for kvm to intercept cr* reads
> on svm hardware. The current kvm code just ends up returning
> the register
>
> Signed-off-by: Joel Schopp
> ---
> arch/x86/kvm/svm.c | 41 -
> 1 file changed, 4
There isn't really a valid reason for kvm to intercept cr* reads
on svm hardware. The current kvm code just ends up returning
the register
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 41 -
1 file changed, 4 insertions(+), 37 deletions(-)
diff -
6 matches
Mail list logo