On Mon, Dec 14, 2015 at 07:17:27PM -0500, Raj, Ashok wrote:
> I can see how this hurts.. since the poller isn't doing cpu model
> specific stuff..?
The poller sees mca_cfg.ser set on an AMD guest and then the whole
handling/decoding goes wrong.
> in the LMCE case, even if you advertise
On Mon, Dec 14, 2015 at 02:23:56PM -0200, Eduardo Habkost wrote:
> > -#define MCE_CAP_DEF (MCG_CTL_P|MCG_SER_P)
> > +#define MCE_CAP_DEF (MCG_CTL_P|MCG_SER_P|MCG_LMCE_P)
>
> This makes mcg_cap change when upgrading QEMU.
>
> VMs with MCG_LMCE_P enabled shouldn't be migratable to hosts
>
On Mon, Dec 14, 2015 at 02:11:46PM -0500, Raj, Ashok wrote:
> This is mostly harmless.. since the MCG_CAP space is shared and has no
> conflict between vendors. Also just the CAP being set has no effect.
Of course it does - we check SER_P in machine_check_poll() and when
I emulate an AMD guest
On Thu, Dec 10, 2015 at 07:15:19PM +0100, Paolo Bonzini wrote:
> Yeah, wait_lapic_expire also have to be moved before __kvm_guest_enter.
Yeah, v2 doesn't splat on the Intel box anymore but the AMD box still
has, and it is a different problem. With the v2 applied, it still
explodes, see below.
On Fri, Dec 11, 2015 at 11:41:30AM +0100, Paolo Bonzini wrote:
> You can disable it (well, make it take a few days to appear) with this:
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 484079efea5b..a9070e260c72 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
>
On Thu, Dec 10, 2015 at 06:38:57PM +0100, Paolo Bonzini wrote:
> Invoking tracepoints within kvm_guest_enter/kvm_guest_exit causes a
> lockdep splat.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Borislav Petkov <b...@alien8.de>
> Signed-off-by: Paolo Bonzini <pbonz..
On Thu, Dec 10, 2015 at 05:49:10PM +0100, Paolo Bonzini wrote:
> Can you try it on Intel?
Just did, there it splats even when booting the guest, without even
injecting NMIs:
[ 113.233992] ===
[ 113.238192] [ INFO: suspicious RCU usage. ]
[ 113.242393] 4.4.0-rc4+ #1
Yap,
this is clearly a qemu/kvm issue. Lemme remove ext4 folks from CC. So
here's what happens:
I boot a kvm guest, connect to its monitor (qemu is started with
"-monitor pty") and on the monitor I issue a couple of times the "nmi"
command. It doesn't explode immediately but it happens pretty
On Wed, Nov 25, 2015 at 01:49:49PM -0200, Eduardo Habkost wrote:
> Instead of silently clearing mcg_cap bits when the host doesn't
> support them, print a warning when doing that.
Why the host? Why would we want there to be any relation between the MCA
capabilities of the host and what qemu is
On Wed, Nov 25, 2015 at 06:29:25PM +0100, Paolo Bonzini wrote:
> On 25/11/2015 18:21, Borislav Petkov wrote:
> >> Instead of silently clearing mcg_cap bits when the host doesn't
> >> > support them, print a warning when doing that.
> > Why the host? Why would we
On Tue, Nov 24, 2015 at 02:36:20PM -0200, Eduardo Habkost wrote:
> KVM_X86_SET_MCE does not call kvm_vcpu_ioctl_x86_setup_mce(). It
> calls kvm_vcpu_ioctl_x86_set_mce(), which stores the
> IA32_MCi_{STATUS,ADDR,MISC} register contents at
> vcpu->arch.mce_banks.
Ah, correct. I've mistakenly
On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote:
> On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote:
> [...]
> > In the case of this code, it looks like it's already broken
> > because the resulting mcg_cap depends on host kernel capabilities
> > (the ones reported
+ Tony.
On Mon, Nov 23, 2015 at 03:47:44PM +0100, Paolo Bonzini wrote:
> On 23/11/2015 14:22, Eduardo Habkost wrote:
> > > Software Error Recovery, i.e. SER, is purely an Intel feature and it
> > > shouldn't be set by default. Enable it only on Intel.
> >
> > What happens when SER is enabled on
On Mon, Nov 23, 2015 at 05:42:08PM -0200, Eduardo Habkost wrote:
> I will let the people working on the actual MCE emulation in KVM
> answer that. I am assuming that KVM_MCE_CAP_SUPPORTED is set to
> something that makes sense.
Well, that should be, IMHO, the same like all those feature bits
From: Borislav Petkov <b...@suse.de>
It looks like this in action:
kvm [5197]: vcpu0, guest rIP: 0x810187ba unhandled rdmsr: 0xc001102
and helps to pinpoint quickly where in the guest we did the unsupported
thing.
Signed-off-by: Borislav Petkov <b...@suse.de>
---
i
From: Borislav Petkov <b...@suse.de>
Software Error Recovery, i.e. SER, is purely an Intel feature and it
shouldn't be set by default. Enable it only on Intel.
Signed-off-by: Borislav Petkov <b...@suse.de>
---
target-i386/cpu.c | 7 ---
target-i386/cpu.h | 9 -
target-i3
On Sat, Nov 21, 2015 at 12:11:35AM +0100, Andreas Färber wrote:
> Hi,
>
> CC'ing qemu-devel.
Ah, thanks.
> Am 21.11.2015 um 00:01 schrieb Borislav Petkov:
> > From: Borislav Petkov <b...@suse.de>
> >
> > Software Error Recovery, i.e. SER, is purely an Intel
On Thu, Nov 19, 2015 at 10:34:07AM +0100, Paolo Bonzini wrote:
> Let me know if I should include this patch via the KVM tree. Do you
> want it in 4.4?
Nah, no need.
I'll send the whole pile with your Reviewed-by's to Ingo so that they
all go together. I'll run them some more on my boxes first
kes sense:
---
commit 804437270083a1aabf87f65f65b32e2ae23121b6
Author: Borislav Petkov <b...@suse.de>
Date: Sat Nov 14 10:54:22 2015 +0100
x86/cpu: Unify CPU family, model, stepping calculation
Add generic functions which calc family, model and stepping from the
CPUID_1.EAX leaf
On Wed, Nov 18, 2015 at 12:10:08PM +0100, Paolo Bonzini wrote:
> On 14/11/2015 11:37, Borislav Petkov wrote:
> > vendor = x86_vendor();
> > - family = x86_family();
> > + family = x86_family_cpuid();
>
> What about renaming x86_vendor() so that this l
From: Borislav Petkov <b...@suse.de>
Add generic functions which calc family, model and stepping from the
CPUID_1.EAX leaf and stick them into the library we have.
No functionality change.
Signed-off-by: Borislav Petkov <b...@suse.de>
---
arch/x86/include/asm/cpu.h|
From: Borislav Petkov <b...@suse.de>
The kernel accesses IC_CFG MSR (0xc0011021) on AMD because it checks
whether the way access filter is enabled on some F15h models, and, if
so, disables it.
kvm doesn't handle that MSR access and complains about it, which can
get really noisy in dmesg wh
From: Borislav Petkov <b...@suse.de>
Hi all,
so this is something which should help fixing the MSR access to IC_CFG
on AMD.
The usefulness should come, however, from the unification and the
additional family, model, stepping helpers in kvm in case one wants to
know those of the guest CP
From: Borislav Petkov <b...@suse.de>
Those give the family, model and stepping of the guest vcpu.
Signed-off-by: Borislav Petkov <b...@suse.de>
Cc: Paolo Bonzini <pbonz...@redhat.com>
---
arch/x86/kvm/cpuid.h | 34 ++
1 file changed, 34 inserti
Hey Paolo,
do we apply stuff like that below?
When booting guests all the time here, dmesg gets filled up with those
"unhandled rdmsr" useless warnings. The patch below shuts them up.
The only problem is that the IC CFG MSR has those fields
defined starting from F15h and I don't see a way to
On Thu, Nov 12, 2015 at 11:59:58AM +0100, Borislav Petkov wrote:
> On Thu, Nov 12, 2015 at 11:33:33AM +0100, Paolo Bonzini wrote:
> > Yes, see guest_cpuid_has_* for an example of reading the CPUID values.
> >
> > But if it's defined for _all_ models starting at family 2
On Thu, Nov 12, 2015 at 11:33:33AM +0100, Paolo Bonzini wrote:
> Yes, see guest_cpuid_has_* for an example of reading the CPUID values.
>
> But if it's defined for _all_ models starting at family 21, we can just
> do it unconditionally.
The thing is, those bits are Reserved again on the next
On Thu, Sep 24, 2015 at 11:23:08AM +0800, Xiao Guangrong wrote:
> >+static inline bool
> >+boot_cpu_is_amd(void)
> >+{
> >+WARN_ON_ONCE(!tdp_enabled);
> >+return shadow_x_mask != 0;
>
> shadow_x_mask != 0 is Intel's CPU.
>
> Borislav, could you please check shadow_x_mask == 0 instead and
On Wed, Sep 23, 2015 at 11:36:47AM +0200, Paolo Bonzini wrote:
> And another patch, which both cranks up the debugging a bit and
> tries another fix:
>
> diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
> index dd05b9cef6ae..b2f49bb15ba1 100644
> --- a/arch/x86/kvm/cpuid.h
> +++
On Tue, Sep 22, 2015 at 11:04:38PM +0200, Paolo Bonzini wrote:
> Let's add more debugging output:
Here you go:
[ 50.474002] walk_shadow_page_get_mmio_spte: detect reserved bits on spte,
addr 0xb8000 (level 4, 0xf00f8)
[ 50.484249] walk_shadow_page_get_mmio_spte: detect reserved bits
On Tue, Sep 22, 2015 at 10:25:29AM +0200, Paolo Bonzini wrote:
> 29ecd6601904 ("KVM: x86: avoid uninitialized variable warning",
> 2015-09-06) introduced a not-so-subtle problem, which probably
> escaped review because it was not part of the patch context.
...
> diff --git a/arch/x86/kvm/mmu.c
e TSC; "
> "guest TSC will not be reliable\n");
>
> + idx = srcu_read_lock(>srcu);
> vcpu = kvm_x86_ops->vcpu_create(kvm, id);
> + srcu_read_unlock(>srcu, idx);
>
> return vcpu;
Other than that, it works.
Teste
On Mon, Sep 21, 2015 at 05:19:57PM +0200, Paolo Bonzini wrote:
> First, the leaf test would have to be == 0, because I prepared the
> patch on the first 4.3 pull request instead of the latest Linus
> tree. However even this would not be a good change, because
>
> is_shadow_present_pte(spte) ==
Hey Paolo,
just triggered this on rc1+tip with a 32-bit guest:
[26421.303750] ===
[26421.307952] [ INFO: suspicious RCU usage. ]
[26421.312161] 4.3.0-rc1+ #1 Not tainted
[26421.312161] ---
[26421.312162] include/linux/kvm_host.h:488
On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
Wasn't me:
6c62aa4a3c12 ("x86: make amd.c have 64bit support code")
I think the error handling of rdmsrl_safe() was needed to do the pfn
games which are done
n 0, meaning that processor protection of SMRAM is not
> in effect.
>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
> arch/x86/include/asm/msr-index.h | 1 +
> arch/x86/kvm/x86.c | 2 ++
> 2 files changed, 3 insertions(+)
Acked-by: Borislav P
On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote:
> Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until
Why not? It is the tseg base address.
I think this is kvm injecting a #GP as it is not ignoring this MSR.
Presumably modprobing kvm with "ignore_msrs=1" or so
On Thu, Sep 17, 2015 at 09:19:20AM +0200, Ingo Molnar wrote:
> Most big distro kernels on bare metal have CONFIG_PARAVIRT=y (I checked
> Ubuntu and
> Fedora), so we are potentially exposing a lot of users to problems.
+ SUSE.
> Crashing the bootup on an unknown MSR is bad. Many MSR reads and
On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote:
> That's not a big deal, that's what *_safe is for. The problem is that
> there are definitely some cases where the *_safe version is not being used.
I mean to do feature checks which assure you that those MSRs are
there so you don't
On Thu, Sep 17, 2015 at 04:32:53PM +0100, Andrew Cooper wrote:
> There are plenty of non-architectural MSRs in use which don't have
> feature bits.
That's exactly what the "possible" adjective was supposed to represent.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Tue, Jun 16, 2015 at 05:36:01PM -0700, Andy Lutomirski wrote:
Now that there is no paravirt TSC, the native is inappropriate.
The function does RDTSC, so give it the obvious name: rdtsc()
Suggested-by: Borislav Petkov b...@suse.de
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch
On Wed, Jun 17, 2015 at 09:47:08AM +0200, Paolo Bonzini wrote:
On 17/06/2015 02:36, Andy Lutomirski wrote:
__pvclock_read_cycles had an unnecessary barrier. Get rid of that
barrier and clean up the code by just using rdtsc_ordered().
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Radim
On Tue, Jun 16, 2015 at 05:35:51PM -0700, Andy Lutomirski wrote:
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ([PATCH] paravirt: header
and stubs for paravirtualisation). AFAICT the only paravirt guest
implementation that ever
On Fri, Jun 19, 2015 at 09:14:14AM -0700, Andy Lutomirski wrote:
Want to fix up the commit message? It seems silly to re-send the
whole series for this.
Of couse, done.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list:
On Tue, Jun 16, 2015 at 05:35:48PM -0700, Andy Lutomirski wrote:
My sincere apologies for the spam. I send an unholy mixture of the
real patch set and an old poorly split-up patch set, and the result
is incomprehensible. Here's what I meant to send.
After the some recent threads about
+-
arch/x86/include/asm/tsc.h| 2 +-
arch/x86/kernel/apb_timer.c | 4 ++--
arch/x86/kernel/tsc.c | 6 --
7 files changed, 9 insertions(+), 17 deletions(-)
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails
| 2 +-
arch/x86/lib/delay.c | 2 +-
drivers/thermal/intel_powerclamp.c | 4 ++--
tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c | 4 ++--
14 files changed, 22 insertions(+), 28 deletions(-)
Acked-by: Borislav
changed, 1 insertion(+), 14 deletions(-)
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
--
arch/x86/xen/enlighten.c | 3 ---
6 files changed, 8 insertions(+), 51 deletions(-)
Nice diffstat.
Acked-by: Borislav Petkov b...@suse.de
(leaving in the rest for reference)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 88711470af7f..d1afac7df484
to NULL and make the initial
isr_count depend on hwapic_isr_update() for good measure.
Fixes: b4eef9b36db4 (kvm: x86: vmx: NULL out hwapic_isr_update() in case of
!enable_apicv)
Reported-by: Borislav Petkov b...@alien8.de
Reported-and-tested-by: Borislav Petkov b...@suse.de
Signed-off
Hi,
commit in $Subject breaks my kvm guest on AMD host, causing it to do the
following below. Mouse doesn't work anymore in the guest, network is
gone too.
Reverting it fixes the issue.
---
...
[4.849095] Freeing unused kernel memory: 2972K (81aee000 -
81dd5000)
[
On Fri, Feb 20, 2015 at 12:39:40PM -0600, Joel Schopp wrote:
KVM has nice wrappers to access the register values, clean up a few places
that should use them but currently do not.
Signed-off-by:David Kaplan david.kap...@amd.com
Signed-off-by:Joel Schopp joel.sch...@amd.com
This SOB chain
and testing]
Signed-off-by: Joel Schopp joel.sch...@amd.com
Looks good.
Acked-by: Borislav Petkov b...@suse.de
---
arch/x86/kvm/svm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d319e0c..a7d88e4 100644
From: Borislav Petkov b...@suse.de
arch/x86/kvm/emulate.c: In function ‘check_cr_write’:
arch/x86/kvm/emulate.c:3552:4: warning: left shift count = width of type
rsvd = CR3_L_MODE_RESERVED_BITS ~CR3_PCID_INVD;
happens because sizeof(UL) on 32-bit is 4 bytes but we shift it 63 bits
the syscall has been done so that paths can get simplified. Which
is a good thing, AFAICT.
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On Fri, Nov 07, 2014 at 03:58:18PM -0800, Andy Lutomirski wrote:
+ /*
+ * Try to use SYSRET instead of IRET if we're returning to
+ * a completely clean 64-bit userspace context.
+ */
+ movq (RCX-R11)(%rsp), %rcx
+ cmpq %rcx,(RIP-R11)(%rsp) /* RCX ==
On Fri, Nov 07, 2014 at 03:58:18PM -0800, Andy Lutomirski wrote:
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 3710b8241945..a5afdf0f7fa4 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -804,6 +804,54 @@ retint_swapgs: /*
On Thu, Jan 08, 2015 at 01:29:28PM +0100, Borislav Petkov wrote:
Ok, dammit, it happened again:
Running -rc+ 2without your first two patches doesn't trigger it. Well,
I don't know what workload even triggered it, it used to happen during
system upgrade. I left the box without your patches
On Tue, Jan 06, 2015 at 08:00:41PM +0100, Borislav Petkov wrote:
I'll redo the whole games tomorrow.
Ok I can't reproduce today either. Let's ascribe it to this particular
test box being funny or something in 3.19-rcs.
We can look at it if it happens again.
Thanks.
--
Regards/Gruss
On Tue, Jan 06, 2015 at 10:43:57AM -0800, Andy Lutomirski wrote:
Sure, but the code would be simpler if we shoved that value in the
EFLAGS slot.
There probably is some reason for that but it's not like we can change
it :-)
Hmm. I added and pushed a test for fork, but that didn't turn
On Mon, Jan 05, 2015 at 12:31:15PM -0800, Andy Lutomirski wrote:
Do you have context tracking on?
Yap, it is enabled for whatever reason:
CONFIG_CONTEXT_TRACKING=y
CONFIG_CONTEXT_TRACKING_FORCE=y
CONFIG_HAVE_CONTEXT_TRACKING=y
I assume that's in the historical tree?
Yeah.
[ 180.059170]
On Fri, Nov 07, 2014 at 03:58:17PM -0800, Andy Lutomirski wrote:
The int_ret_from_sys_call and syscall tracing code disagrees with
the sysret path as to the value of RCX.
The Intel SDM, the AMD APM, and my laptop all agree that sysret
returns with RCX == RIP. The syscall tracing code does
Hi Paolo,
so I installed an old SUSE guest (SLES10, kernel is 2.6.16 + enterprise
stuff) and it was booting and all was fine but this week not anymore.
Host kernel is 3.19-rc1 + tip/master. I did miss some kvm config options
initially so I did
$ make kvmconfig
and it added those (see diff at
On Mon, Dec 08, 2014 at 03:04:59PM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient
On Tue, Dec 02, 2014 at 09:36:40AM -0500, Boris Ostrovsky wrote:
All tests passed.
Thanks!
I wonder whether we should prevent all guests (not just paravirt) from
loading microcode driver (and from doing early microcode loading).
I don't think the unmodified ones need to. At least I haven't
On Mon, Dec 01, 2014 at 11:12:38PM +0100, Paolo Bonzini wrote:
We also do not want to load microcode. :) Thanks for the heads-up.
You don't need to :P
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
I think so. The problem we have now is __pa() macro that we only use
on 32-bit. I'll queue this for overnight tests to make sure and if it
indeed works then 3.19 should be fine.
Cool, thanks.
I'd still take your patch for 3.19
On Thu, Nov 13, 2014 at 12:31:30AM +, Luck, Tony wrote:
Is this something I can try under KVM?
I don't know if KVM has a way to simulate a machine check event.
I've been thinking about it recently too - adding MCA functionality to
qemu/kvm could be very useful, especially the
On Thu, Nov 13, 2014 at 11:59:37AM +0100, Borislav Petkov wrote:
I've been thinking about it recently too - adding MCA functionality to
qemu/kvm could be very useful, especially the thresholding stuff, for
testing RAS kernel code.
Btw, qemu monitor has a mce injection command with which I
On Fri, Nov 07, 2014 at 10:18:32PM -0500, Timothy McDaniel wrote:
Via Nano fails and completely crashes on kvm
here is my /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano processor U2250 (1.6GHz Capable)
.
Cc: sta...@vger.kernel.org
Fixes: 719d5a9b2487e0562f178f61e323c3dc18a8b200
Reported-by: Borislav Petkov b...@suse.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Thanks Paolo, the ept=0 case seems to work now. I'll stress it more
later this week.
Tested-by: Borislav Petkov b...@suse.de
On Tue, Sep 23, 2014 at 10:00:12AM +0200, Paolo Bonzini wrote:
Il 22/09/2014 21:43, Borislav Petkov ha scritto:
On x86_64, kernel text mappings are mapped read-only with
CONFIG_DEBUG_RODATA.
Hmm, that depends on DEBUG_KERNEL.
I think you're actually talking about distro kernels
On Mon, Sep 22, 2014 at 01:17:48PM +0200, Paolo Bonzini wrote:
On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
Hmm, that depends on DEBUG_KERNEL.
I think you're actually talking about distro kernels which enable
CONFIG_DEBUG_RODATA, right?
--
Regards/Gruss,
On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
We're talking about the case where the field is not reserved anymore and
we _know_ that the vendor has just decided to grow the bitfield that
precedes it.
We're talking about the case where you assumed that a reserved bit is 0
On Fri, Sep 19, 2014 at 11:59:32AM +0300, Nadav Amit wrote:
As for the concern that CPUID fields would be extended into non-zero
reserved bits - can someone point me to a single case that occurred in
the last 20 years during which CPUID existed?
Do you have a guarantee that this won't happen
On Fri, Sep 19, 2014 at 03:40:29PM +0200, Paolo Bonzini wrote:
And similarly, Intel would not extend a bit from 16 to 17 bits if it
weren't zero on all older processors.
Nothing is stopping a hw designer to say we're using 17 bits now. And
software needs to deal with that. It is that simple!
On Thu, Sep 18, 2014 at 02:29:54AM +0200, Radim Krčmář wrote:
I think you proposed to use magic constant in place of of MASK_FAM_X, so
Huh, what?
Second problem: Most elements don't begin at offset 0, so the usual
retrieval would add a shift, (repurposing max_monitor_line_size)
So what?
On Thu, Sep 18, 2014 at 03:06:59PM +0200, Paolo Bonzini wrote:
The extra bit used to be reserved and thus will be zero on older
families. So, nothing?
thus will be zero is unfortunately simply not true.
From the SDM:
1.3.2 Reserved Bits and Software Compatibility
In many register and memory
On Wed, Sep 17, 2014 at 02:37:10PM +0200, Ingo Molnar wrote:
Opinions, objections?
Can I see those patches please? I can't find them on lkml or on the net
- I only see this sub-thread...
Thanks.
--
Regards/Gruss,
Boris.
--
--
To unsubscribe from this list: send the line unsubscribe kvm in
On Wed, Sep 17, 2014 at 03:54:12PM +0300, Nadav Amit wrote:
Adding structs that reflect various cpuid fields in x86 architecture. Structs
were added only for functions that are not pure bitmaps.
Signed-off-by: Nadav Amit na...@cs.technion.ac.il
---
arch/x86/include/asm/cpuid_def.h | 163
On Wed, Sep 17, 2014 at 04:53:39PM +0300, Nadav Amit wrote:
AFAIK backward compatibility is usually maintained in x86. I did not
see in Intel SDM anything that says this CPUID field means something
for CPU X and something else for CPU Y. Anyhow, it is not different
than bitmasks in this
On Wed, Sep 17, 2014 at 05:04:33PM +0200, Radim Krčmář wrote:
which would result in a similar if-else hack
if (family X)
ebx.split.max_monitor_line_size_after_family_X = 0
else
ebx.split.max_monitor_line_size = 0
other options are
-by: Alex Bennée alex.ben...@linaro.org
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
--
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mammedov imamm...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 31, 2014 at 09:47:12AM +, Igor Mammedov wrote:
Due to erratum #778 from
Revision Guide for AMD Family 15h Models 10h-1Fh Processors,
Publication # 48931, Issue Date: May 2013, Revision: 3.10
TSC on affected processor, a core may drift under certain conditions,
which makes
From: Borislav Petkov b...@suse.de
While staring at kvm exception code in conjunction with the recent #DF
splat, this function's name was bugging me because it clearly deals with
multiple exceptionS(!) but it is missing the plural in the naming. Fix
that so that I can sleep at night :-)
Signed
On Mon, Jun 30, 2014 at 05:03:57PM +0200, Jan Kiszka wrote:
15.5.1:
When examining segment attributes after a #VMEXIT:
[...]
• Retrieve the CPL from the CPL field in the VMCB, not from any segment
DPL.
Heey, it is even documented! :-P
--
Regards/Gruss,
Boris.
Sent from a fat crate
On Sun, Jun 29, 2014 at 12:59:30PM +0200, Jan Kiszka wrote:
Will see what I can do regarding bisecting. That host is a bit slow
(netbook), so it may take a while. Boris will probably beat me in
this.
Nah, I was about to instrument kvm_multiple_exception() first and am
slow anyway so... :-)
On Sun, Jun 29, 2014 at 02:22:35PM +0200, Jan Kiszka wrote:
OK, looks like I won ;):
I gladly let you win. :-P
The issue was apparently introduced with KVM: x86: get CPL from
SS.DPL (ae9fedc793). Maybe we are not properly saving or restoring
this state on SVM since then.
I wonder if this
On Sun, Jun 29, 2014 at 03:14:43PM +0200, Borislav Petkov wrote:
I better go and revert that one and check whether it fixes things.
Yahaaa, that was some good bisection work Jan! :-)
20 guest restart cycles and all is fine - it used to trigger after 5
max.
Phew, we have it right in time
On Sun, Jun 29, 2014 at 04:42:47PM +0300, Gleb Natapov wrote:
Please do so and let us know.
Yep, just did. Reverting ae9fedc793 fixes the issue.
reinj:1 means that previous injection failed due to another #PF that
happened during the event injection itself This may happen if GDT or fist
which triggered
register saving/restoring to/from host user space.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Yep, looks good.
Tested-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from
[3.704212] ---[ end trace 85735a6f8b08ee31 ]---
[3.704212] note: vmmouse_detect[911] exited with preempt_count 3
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
From b2e6dd5168373feb7548da5521efc40c58409567 Mon Sep 17 00:00:00 2001
From: Borislav Petkov b
On Wed, Jun 25, 2014 at 10:26:50PM +0200, Borislav Petkov wrote:
On Wed, Jun 25, 2014 at 05:32:28PM +0200, Borislav Petkov wrote:
Hi guys,
so I'm looking at this splat below when booting current linus+tip/master
in a kvm guest. Initially I thought this is something related
On Fri, Jun 27, 2014 at 01:41:30PM +0200, Paolo Bonzini wrote:
Il 27/06/2014 12:18, Borislav Petkov ha scritto:
Joerg says I should bisect but I'm busy with other stuff. If people are
interested in chasing this further, I could free up some time to do
so...
Please first try -M pc-1.7
On Fri, Jun 27, 2014 at 02:01:43PM +0200, Paolo Bonzini wrote:
Can you try gathering a trace? (and since those things get huge, you
can send it to me offlist) Also try without ept and see what happens.
Yeah, Joerg just sent me a diff on how to intercept #DF. I'll add a
tracepoint so that it all
Hi guys,
so I'm looking at this splat below when booting current linus+tip/master
in a kvm guest. Initially I thought this is something related to the
PARAVIRT gunk but it happens with and without it.
So, from what I can see, we first #DF and then lockdep fires a deadlock
warning. That I can
On Wed, Jun 25, 2014 at 05:32:28PM +0200, Borislav Petkov wrote:
Hi guys,
so I'm looking at this splat below when booting current linus+tip/master
in a kvm guest. Initially I thought this is something related to the
PARAVIRT gunk but it happens with and without it.
Ok, here's a cleaner
On Thu, Jun 05, 2014 at 04:12:08PM -0300, Eduardo Habkost wrote:
In the meantime, we could:
* Include the less fine-tuned allow-emulation (or
allow-experimental-features) option, which is implemented by this
series, for people who use enforce and/or don't care too much about
On Fri, Jun 06, 2014 at 12:24:26AM +0200, Alexander Graf wrote:
But can we drop the EMULATED name somehow? Can we rename [1] the ioctl
to say GET_UNSUPPORTED_CPUID or something along those lines? The name
is just a really really bad pick.
What do you mean, a bad pick :-P? I added extra care in
1 - 100 of 193 matches
Mail list logo
