From: Tvrtko Ursulin tvrtko.ursu...@sophos.com
Date: Tue, Aug 03, 2010 at 11:31:02AM -0400
One interesting waning spotted:
include/config/auto.conf:555:warning: symbol value '-fcall-saved-ecx
-fcall- saved-edx' invalid for ARCH_HWEIGHT_CFLAGS
Copying Peter and Borislav, guys please
From: Borislav Petkov borislav.pet...@amd.com
Add a wbinvd helper for an arbitrary set of CPUs.
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
---
arch/x86/include/asm/smp.h |4 +++-
arch/x86/lib/cache-smp.c | 12
2 files changed, 15 insertions(+), 1 deletions
From: Borislav Petkov borislav.pet...@amd.com
Replace local wbinvd helpers with equivalent x86 library functions.
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
---
arch/x86/kvm/x86.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/x86
On Wed, Nov 24, 2010 at 12:49:06PM -0500, H. Peter Anvin wrote:
On 11/24/2010 09:44 AM, Borislav Petkov wrote:
From: Borislav Petkov borislav.pet...@amd.com
Add a wbinvd helper for an arbitrary set of CPUs.
Are there any expected users of this other than KVM?
Not that I know of. I
to end of line
Looks useful.
Acked-by: Borislav Petkov b...@alien8.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
Hi all,
just saw this in dmesg while running -rc1 + tip/master:
[ 6983.694615] =
[ 6983.694617] [ INFO: possible recursive locking detected ]
[ 6983.694620] 3.8.0-rc1+ #26 Not tainted
[ 6983.694621] -
[
Hi Hillf,
On Wed, Dec 26, 2012 at 08:18:13PM +0800, Hillf Danton wrote:
Can you please test with 5a505085f0 and 4fc3f1d66b reverted?
sure can do, but am travelling ATM so I'll run it with the reverted
commits when I get back next week.
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from
On Sat, Jan 05, 2013 at 08:00:19PM +0800, Hillf Danton wrote:
Jiri posted similar locking issue at
https://lkml.org/lkml/2013/1/4/380
Take a look?
Yeah, it looks like the same issue. I'll try his patch on Monday.
Thanks for letting me know.
--
Regards/Gruss,
Boris.
--
To
On Fri, Aug 17, 2012 at 03:43:56AM -0400, Tomas Racek wrote:
Well, I've added some debug statements to the code:
void __init arch_init_ideal_nops(void)
{
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_INTEL:
/*
* Due to a decoder
On Thu, Apr 05, 2012 at 01:38:41PM -0700, Tony Luck wrote:
A plain v3.3 kernel hits this when I just type reboot on a 32 cpu (2
socket * 8 core * 2 HT) system:
Same here on latest linus on a 24 CPU box right before the box reboots:
[ 6851.207504] [ cut here ]
[
On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote:
From: Davidlohr Bueso d...@gnu.org
AMD has renamed nested page table technology to rapid virtualization indexing,
reflect this change in the kernel.
Signed-off-by: Davidlohr Bueso d...@gnu.org
You know that /proc/cpuinfo is
On Sat, Jul 14, 2012 at 04:28:51PM +0200, Davidlohr Bueso wrote:
On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote:
Yep, NAK on this one.
Ok, we could at least add a comment when defining X86_FEATURE_NPT.
And the valid, sane, technical reason for having a comment where any
internet
I get the following
In file included from arch/x86/kvm/mmu.c:2856:
arch/x86/kvm/paging_tmpl.h: In function ‘paging32_walk_addr_generic’:
arch/x86/kvm/paging_tmpl.h:124: warning: ‘ptep_user’ may be used uninitialized
in this function
In file included from arch/x86/kvm/mmu.c:2852:
Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Link: http://lkml.kernel.org/r/20110530094604.gc21...@liondog.tnic
Signed-off-by: Borislav Petkov b...@alien8.de
---
arch/x86/kvm/paging_tmpl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm
Looks like a KSM issue. Disabling CONFIG_KSM should at least stop your
machine from oopsing.
Adding linux-mm.
On Tue, May 31, 2011 at 09:24:03AM +0800, Brad Campbell wrote:
G'day all,
I'm running a pretty standard home server
x86_64 Phenom-II 6 Core
16GB DDR 3
I run some virtual
On Tue, May 31, 2011 at 11:20:55AM +0300, Avi Kivity wrote:
On 05/31/2011 10:38 AM, Ingo Molnar wrote:
* Borislav Petkovb...@alien8.de wrote:
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -121,7 +121,7 @@ static int FNAME(walk_addr_generic)(struct
guest_walker *walker,
On Tue, May 31, 2011 at 05:26:10PM +0800, Brad Campbell wrote:
On 31/05/11 13:47, Borislav Petkov wrote:
Looks like a KSM issue. Disabling CONFIG_KSM should at least stop your
machine from oopsing.
Adding linux-mm.
I initially thought that, so the second panic was produced with KSM
On Tue, May 31, 2011 at 12:26:55PM +0200, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 05/31/2011 10:38 AM, Ingo Molnar wrote:
* Borislav Petkovb...@alien8.de wrote:
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -121,7 +121,7 @@ static int FNAME(walk_addr_generic)(struct
On Tue, Feb 12, 2013 at 04:21:13PM -0800, H. Peter Anvin wrote:
On 02/12/2013 04:16 PM, Borislav Petkov wrote:
This family check is redundant, we're already in a 0x10 if-branch
above. Boris had sent a second version which doesn't have that check:
http://marc.info/?l=linux-kernelm
From: Borislav Petkov b...@suse.de
The x86, AMD: Enable WC+ memory type on family 10 processors patch
currently in -tip added a workaround for AMD F10h CPUs which #GPs my
guest when booted in kvm. This is because it accesses MSR_AMD64_BU_CFG2
which is not currently ignored by kvm. Do that because
On Wed, Feb 13, 2013 at 01:47:47PM +0200, Gleb Natapov wrote:
On Wed, Feb 13, 2013 at 12:42:41PM +0100, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
The x86, AMD: Enable WC+ memory type on family 10 processors patch
currently in -tip added a workaround for AMD F10h CPUs
On Wed, Feb 13, 2013 at 02:10:02PM +0200, Gleb Natapov wrote:
Is your guest compiled without PV support? With PV Linux traps #GP for
all MSRs and it saves us in more than one places.
Yes, CONFIG_PARAVIRT_GUEST is not set on the guest kernel.
Thanks. It does not mean that the patch
On Wed, Feb 13, 2013 at 08:31:00AM -0800, Randy Dunlap wrote:
This warning is still present in linux-next (20130213).
Acked-by: Randy Dunlap rdun...@infradead.org
Thanks.
Someone please merge... (kvm@ cc added)
There's a fix already in tip for this:
-signed-off-by: Borislav Petkov b...@suse.de
--
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 15f960c06ff7..ae01c765cd77 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -281,6 +281,7 @@ struct x86_emulate_ctxt
On Wed, Apr 10, 2013 at 01:46:02AM +0200, Borislav Petkov wrote:
+static int em_movbe(struct x86_emulate_ctxt *ctxt)
+{
+ char *valptr = ctxt-src.valptr;
+
+ switch (ctxt-op_bytes) {
+ case 2:
+ *(u16 *)valptr = swab16(*(u16 *)valptr);
+ break
On Tue, Apr 09, 2013 at 05:04:06PM -0700, H. Peter Anvin wrote:
On 04/09/2013 05:03 PM, Borislav Petkov wrote:
Note to self: this destroys the src operand but it shouldn't. Fix it
tomorrow.
I thought movbe was already in qemu just not on by default...?
Yep, this went upstream just
On Wed, Apr 10, 2013 at 01:08:46PM +0300, Gleb Natapov wrote:
We can add the emulation, but we should not start announcing the
instruction availability to a guest if host cpu does not have it
by default. This may trick a guest into thinking that movbe is the
fastest way to do something when it
option or not.
Anyway, here's the second version with hopefully all comments and
suggestions addressed.
Thanks.
--
From 612fc75a732ad16332f270b7c52a68c89e3565ca Mon Sep 17 00:00:00 2001
From: Borislav Petkov b...@suse.de
Date: Thu, 11 Apr 2013 02:06:30 +0200
Subject: [PATCH] kvm: Emulate MOVBE
On Thu, Apr 11, 2013 at 05:28:18PM +0300, Gleb Natapov wrote:
On Thu, Apr 11, 2013 at 02:18:15AM +0200, Borislav Petkov wrote:
On Wed, Apr 10, 2013 at 03:16:39PM +0300, Gleb Natapov wrote:
Right, the question is how kernel can tell QEMU that the cpuid bit is
supported but should
On Sun, Apr 14, 2013 at 10:41:07AM +0300, Gleb Natapov wrote:
Currently userspace assumes that that cpuid configuration returned by
KVM_GET_SUPPORTED_CPUID is the optimal one. What we want here is a way
for KVM to tell userspace that it can emulate movbe though it is not
optimal.
Ok, I don't
On Sun, Apr 14, 2013 at 11:36:29AM -0700, H. Peter Anvin wrote:
Just to interject here... all this is about host kernel vs userspace,
correct? I.e. nothing that affects the guest. I assume that the guest
sees CPUID and that is what is supported.
Actually, currently the guest sees MOVBE in
On Sun, Apr 14, 2013 at 11:43:03AM +0300, Gleb Natapov wrote:
+#define EmulateOnUD ((u64)1 46) /* emulate if unsupported by the host
*/
Just rename VendorSpecific to EmulateOnUD. The meaning is the same.
done.
+static int em_movbe(struct x86_emulate_ctxt *ctxt)
+{
+ switch
On Tue, Apr 16, 2013 at 01:47:46PM +0200, Paolo Bonzini wrote:
Atom is not defined by QEMU;
$ qemu-system-x86_64 -cpu ?
...
x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe
On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
I obviously support having something like this in mainline. I wonder
though if we could just call this default standalone KVM guest
config instead of emphasizing
On Tue, Apr 16, 2013 at 08:38:56PM -0400, Sasha Levin wrote:
select NET
select NETDEVICES
select PCI
select BLOCK
select BLK_DEV
select NETWORK_FILESYSTEMS
select INET
select EXPERIMENTAL
select TTY
select SERIAL_8250
select
On Tue, Apr 16, 2013 at 08:42:36PM +0300, Gleb Natapov wrote:
Right, and this is what we have, AFAICT. And if userspace does that what
you exemplify above, you get exactly that - a feature bit not set in
CPUID but KVM reporting it set means, it is emulated. There's no room
for other
On Wed, Apr 17, 2013 at 04:38:29PM +0300, Gleb Natapov wrote:
Yes, but it is good emulation. You want to have it for performance
even if host does not have x2apic. x2apic is emulated no matter if
host cpu has it or not. movbe is different, you want to emulate it
only if your guest requires it.
On Wed, Apr 17, 2013 at 08:25:07PM -0300, Marcelo Tosatti wrote:
On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
I obviously support having
On Thu, Apr 18, 2013 at 11:55:33AM +0200, Geert Uytterhoeven wrote:
On Thu, Apr 18, 2013 at 11:46 AM, Borislav Petkov b...@alien8.de wrote:
ok, maybe I wasn't clear enough. My proposal was to actually add all (or
maybe not *all* of them, but most) those selects above to the KVM_GUEST
config
On Wed, Apr 17, 2013 at 04:02:00PM +0200, Borislav Petkov wrote:
Right, so basically we want to handle features which were explicitly
enabled only for this guest as private, only relevant to this
particular guest run.
Ok,
here are two more ideas Joerg and I had today during lunch:
* reuse
On Thu, Apr 18, 2013 at 10:36:31AM -0300, Marcelo Tosatti wrote:
IOW, something which says Enable KVM guest support should enable all
the stuff needed for that.
I get your point, but thats up to the person selecting the options.
Ok.
Or do you want to keep the current CONFIG_KVM_GUEST
On Sun, Apr 21, 2013 at 12:46:51PM +0300, Gleb Natapov wrote:
There may be userspaces that set -function to 0x (just
because they do not init the buffer before calling into the kernel)
and this will break them.
You don't mean 0x here but rather something random which is not
On Tue, Apr 16, 2013 at 01:36:00PM +0200, Paolo Bonzini wrote:
Il 14/04/2013 23:02, Borislav Petkov ha scritto:
*(u16 *)ctxt-dst.val = swab16((u16)ctxt-src.val);
movzwl 112(%rdi), %eax # ctxt_5(D)-src.D.27823.val, tmp82
rolw$8, %ax #, tmp82
movw%ax, 240(%rdi
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values to a temp variable or so.
Basically something like that:
case 2:
/*
* From MOVBE definition: ...When the operand size is 16 bits
On Mon, Apr 22, 2013 at 10:53:42AM +0200, Paolo Bonzini wrote:
Il 21/04/2013 14:23, Borislav Petkov ha scritto:
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values to a temp variable or so.
Basically something like
On Mon, Apr 22, 2013 at 12:42:46PM +0300, Gleb Natapov wrote:
Btw, I wanted to ask: when kvm commits the results, does it look at
ctxt-op_bytes to know exactly how many bytes to write to the guest?
Because if it does, we can save ourselves the trouble here.
Or does it simply write both
On Mon, Apr 22, 2013 at 12:58:12PM +0300, Gleb Natapov wrote:
For most instructions the decoder already sets op-bytes to correct
value, given that all flags a correctly specified in opcode table.
Explicit op-bytes setting should be done only if it cannot be
expressed by opcode flags.
MOVBE
On Sun, Apr 21, 2013 at 03:51:16PM +0300, Gleb Natapov wrote:
Not nice?! It is a very nasty hack - that's what it is. :-)
Agree, but not nastier than expecting -function to have special value :)
Probably of the same nastiness level :-)
Frankly speaking, I'd rather prefer adding a new
On Tue, Apr 23, 2013 at 04:50:43PM -0700, H. Peter Anvin wrote:
On 04/23/2013 04:41 PM, Borislav Petkov wrote:
Btw, in thinking about this more, I'm kinda sceptical we want to use the
CPUID layout for this new KVM_GET_EMULATED_* ioctl. And the reason why
I'm sceptical is that not every
From: Borislav Petkov b...@suse.de
It is exit_int_info. It is actually EXITINTINFO in the official docs
but we don't like screaming docs.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b
From: Borislav Petkov b...@suse.de
Date: Tue, 16 Apr 2013 18:24:34 +0200
Subject: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm. Instead of going and searching for each
required option
On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
... take all review comments
Here it is:
--
From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
From: Borislav Petkov b...@suse.de
Date: Tue, 16 Apr 2013 18:24:34 +0200
Subject: [PATCH -v2.1] x86: Add a Kconfig
On Mon, Apr 22, 2013 at 11:38:10AM +0200, Borislav Petkov wrote:
On Mon, Apr 22, 2013 at 10:53:42AM +0200, Paolo Bonzini wrote:
Il 21/04/2013 14:23, Borislav Petkov ha scritto:
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values
On Wed, May 01, 2013 at 10:19:24AM -0300, Marcelo Tosatti wrote:
Applied, thanks.
You shouldn't have - Ingo took it already.
--
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 of
On Tue, Jun 25, 2013 at 02:10:20PM +0300, Gleb Natapov wrote:
- if (!(ctxt-d VendorSpecific) ctxt-only_vendor_specific_insn)
+ if (!(ctxt-d EmulateOnUD) ctxt-only_vendor_specific_insn)
Lets rename only_vendor_specific_insn to something like -ud too.
So this thing is set only when
Fix kvm ML already.
On Tue, Jul 16, 2013 at 12:39:30AM +0200, Borislav Petkov wrote:
On Sun, Jul 07, 2013 at 01:18:27PM +0300, Gleb Natapov wrote:
KVM does not enables emulation because QEMU called
KVM_GET_EMULATED_CPUID. KVM enables emulation because QEMU sets
MOVBE bit in a guest visible
From: Borislav Petkov b...@suse.de
Add a kvm ioctl which states which system functionality kvm emulates.
The format used is that of CPUID and we return the corresponding CPUID
bits set for which we do emulate functionality.
Make sure -padding is being passed on clean from userspace so that we
From: Borislav Petkov b...@suse.de
Add support for the KVM_GET_EMULATED_CPUID ioctl and leave feature bits
enabled, when requested by userspace, if kvm emulates them.
Signed-off-by: Borislav Petkov b...@suse.de
---
include/sysemu/kvm.h | 4
linux-headers/linux/kvm.h | 4
target
From: Borislav Petkov b...@suse.de
Add initial support for handling three-byte instructions in the
emulator.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/kvm/emulate.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/x86/kvm/emulate.c b/arch
From: Borislav Petkov b...@suse.de
Alriiight,
here's another version of the patchset, hopefully addressing all review
feedback from last time. 6/6 is the respective qemu patch to handle
emulated features query, etc.
It is still a lot of fun to generate fast! Atom 32-bit SMP guests like
From: Borislav Petkov b...@suse.de
Call it EmulateOnUD which is exactly what we're trying to do with
vendor-specific instructions.
Rename -only_vendor_specific_insn to something shorter, while at it.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/kvm_emulate.h | 2
From: Borislav Petkov b...@suse.de
Add a field to the current emulation context which contains the
instruction opcode length. This will streamline handling of opcodes of
different length.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/kvm_emulate.h | 8 ++--
arch/x86
From: Borislav Petkov b...@suse.de
This basically came from the need to be able to boot 32-bit Atom SMP
guests on an AMD host, i.e. a host which doesn't support MOVBE. As a
matter of fact, qemu has since recently received MOVBE support but we
cannot share that with kvm emulation and thus we have
On Mon, September 23, 2013 6:28 pm, Eduardo Habkost wrote:
On Sun, Sep 22, 2013 at 04:44:50PM +0200, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
Add a kvm ioctl which states which system functionality kvm emulates.
The format used is that of CPUID and we return the corresponding
On Thu, Sep 26, 2013 at 11:19:15AM -0300, Eduardo Habkost wrote:
Then we may have a problem: some CPU models already have movbe
included (e.g. Haswell), and patch 6/6 will make -cpu Haswell get
movbe enabled even if it is being emulated.
Huh? HSW has MOVBE so we won't #UD on it and MOVBE will
On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote:
Please point me to the code that does this, because I don't see it on
patch 6/6.
@@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
wi-cpuid_ecx,
On Fri, Sep 27, 2013 at 11:21:34AM -0300, Eduardo Habkost wrote:
The problem here is that requested_features doesn't include just
the explicit +flag flags, but any flag included in the CPU model
definition. See the -cpu n270 example below.
Oh, you mean if requested_features would contain a
Btw,
while I got your attention, on a not-really related topic: how do we
feel about adding support for specifying a non-contiguous set of cpus
for a numa node in qemu with the -numa option? I.e., like this, for
example:
x86_64-softmmu/qemu-system-x86_64 -smp 8 -numa node,nodeid=0,cpus=0\;2\;4-5
On Mon, Sep 30, 2013 at 11:05:10AM +0200, Paolo Bonzini wrote:
I think there are already patches on the list to do that, as part of
the NUMA memory binding series from Wanlong Gao.
Yeah: https://lists.gnu.org/archive/html/qemu-devel/2013-09/msg02833.html
Although I don't see from it how the
On Mon, Sep 30, 2013 at 01:13:34PM -0300, Eduardo Habkost wrote:
I have added it to my TODO-list. :-)
Cool, thanks. Let me know if I can test stuff and help out somehow.
Also, there's another aspect, while we're here: now that QEMU emulates
MOVBE with TCG too, how do we specify on the
the pagetables,
but does it without any apparent performance loss versus the current
broken version.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Joerg Roedel j...@8bytes.org
Signed-off-by: Borislav Petkov b...@suse.de
On Tue, Oct 29, 2013 at 11:50:43AM +0200, Gleb Natapov wrote:
There are two three opcode tables, so third_opcode_byte is ambiguous.
Actually there's also 0F_3A and there are also other prefixes besides f0
and f1. Oh, and those tables are not completely full so I can imagine
more stuff coming in
On Tue, Oct 29, 2013 at 11:53:00AM +0200, Gleb Natapov wrote:
Except a small nitpick for patch 4 this looks good to me. No need to
wait for QEMU cpu parsing code to change to apply it.
Ok, want a resend or rather a pull request or only patch 4 resend?
Btw, we kinda missed each other in
On Tue, Oct 29, 2013 at 12:35:24PM +0200, Gleb Natapov wrote:
If everything still applies patch 4 resend should be fine.
Which tree should they still apply to?
Yeah, kvm forum was not at the same building as LinuxCon :(
Yep, I know. We did go to the kvm forum to use the wifi there because
the
On Tue, Oct 29, 2013 at 01:36:03PM +0200, Gleb Natapov wrote:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue branch.
Ok, they still apply.
I'm sending 4 and 5 (5 needed changes too) as a reply to this message.
That's why we got max users limit is reached error! (only for the
first half
From: Borislav Petkov b...@suse.de
Add initial support for handling three-byte instructions in the
emulator.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/kvm/emulate.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/x86/kvm/emulate.c b/arch
From: Borislav Petkov b...@suse.de
This basically came from the need to be able to boot 32-bit Atom SMP
guests on an AMD host, i.e. a host which doesn't support MOVBE. As a
matter of fact, qemu has since recently received MOVBE support but we
cannot share that with kvm emulation and thus we have
On Wed, Oct 30, 2013 at 06:56:10PM +0100, Paolo Bonzini wrote:
Thanks, I've applied these patches to kvm/queue.
Cool.
As I'm sure I'll miss the qemu development, please ping me when the qemu
side is ready for adding the KVM_GET_EMULATED_CPUID thing there.
Thanks.
--
Regards/Gruss,
Boris.
On Wed, Oct 30, 2013 at 07:10:56PM +0100, Paolo Bonzini wrote:
I tested this patch manually with a small C test program and asm.
Would you please prepare a patch to kvm-unit-tests that stresses the new
codepath?
Ha, now that you bring that up, I think Andre already had something
ready.
On Thu, Oct 31, 2013 at 03:49:04PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:34, Gleb Natapov ha scritto:
I haven't checked AMD doc, but if it is documented that lahf/sahf #UDs at 64
bit we should emulate it correctly.
It says The LAHF instruction can only be executed in 64-bit mode if
}
569return false;
Ok, how's that:
--
From: Borislav Petkov b...@suse.de
Subject: [PATCH] kvm, cpuid: Fix sparse warning
We need to copy padding to kernel space first before looking at it.
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Borislav
On Sat, Dec 07, 2013 at 02:52:54AM +0800, Qiaowei Ren wrote:
This patch adds the Documentation/intel_mpx.txt file with some
information about Intel MPX.
Signed-off-by: Qiaowei Ren qiaowei@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Liu Jinsong
On Sat, Dec 07, 2013 at 02:52:55AM +0800, Qiaowei Ren wrote:
Signed-off-by: Qiaowei Ren qiaowei@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Liu Jinsong jinsong@intel.com
---
arch/x86/include/asm/cpufeature.h |2 ++
1 files changed, 2 insertions(+),
On Sat, Dec 07, 2013 at 02:52:56AM +0800, Qiaowei Ren wrote:
Commit message please.
Signed-off-by: Qiaowei Ren qiaowei@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Liu Jinsong jinsong@intel.com
---
arch/x86/include/asm/processor.h | 23
On Fri, Dec 06, 2013 at 03:55:10PM +, Ren, Qiaowei wrote:
It is from public introduction and specification, you can refer to
http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions
Yep, saw it there too. Which doesn't make it any less strange :)
Btw, if
On Fri, Dec 06, 2013 at 09:23:22AM -0800, H. Peter Anvin wrote:
On 12/06/2013 05:46 AM, Borislav Petkov wrote:
I'm guessing this and the struct lwp_struct above is being added so that
you can have the LWP XSAVE area size? If so, you don't need it: LWP
XSAVE area is 128 bytes at offset 832
On Wed, Feb 12, 2014 at 11:37:13AM +0100, Peter Zijlstra wrote:
Another reporter also saw this on an AMD and said it could not be
reproduced on
the same hardware and the same software versions when using 64bit instead
of 32.
In my case on a 32bit installation I will see this on
On Thu, Feb 13, 2014 at 07:26:05PM +0100, Peter Zijlstra wrote:
On Thu, Feb 13, 2014 at 07:03:56PM +0100, Stefan Bader wrote:
Yeah... not sure the interleaved source helps or not ...
It did, thanks!
Stefan, can you also send sched/core.s? I'm particularly interested in
what resched_task()
On Fri, Feb 14, 2014 at 03:24:09PM +0100, Stefan Bader wrote:
Actually, this code just makes so much more sense if I let objdump do
relocation info...
Ok, we're pretty sure you have an MFENCE there in resched_task but can
you confirm it please.
First, does /proc/cpuinfo have the sse2 string?
Oh, and just in case this is relatively easy to reproduce and in case we
don't have any other idea, bisection might be another option. I'm not
saying you should do it right away - I'm just putting it on the table...
:-)
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk.
On Fri, Feb 14, 2014 at 04:28:16PM +0100, Stefan Bader wrote:
Oh yeah, bisection is nearly as entertaining as doing my tax records.
Hm, on the other hand those will have to be done at some point too...
:-P
Ah, tax records, crap, I have those lying around in the corner since
forever... I need
On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu info.
And
there is a mfence in the disassembly:
Btw, I just realized booting the kernel in the guest was a dumb idea,
because, doh, the guest is not baremetal.
On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
That should be the purpose of KVM_GET_EMULATED_CPUID, so MWAIT could be
added in __do_cpuid_ent_emulated. However, the corresponding QEMU patches
were never included. Borislav, can you refresh them?
/me goes and swaps in all the
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
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 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
1 - 100 of 193 matches
Mail list logo
