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
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
+ Matt.
On Wed, Jul 31, 2013 at 02:10:04PM +0200, Laszlo Ersek wrote:
Just random ideas...
First of all, thanks for looking. You made me look too and find the fun
:-)
The fact that you guys didn't say Oh yeah, we do this because... but
simply shruggingly suggested ideas should've been enough
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 Thu, Aug 09, 2012 at 02:33:12PM +0530, Amit Shah wrote:
@@ -807,9 +807,31 @@ static int pipe_to_sg(struct pipe_inode_info *pipe,
struct pipe_buffer *buf,
len = min(buf-len, sd-len);
sg_set_page((sgl-sg[sgl-n]), buf-page, len, buf-offset);
-
On Tue, Jun 05, 2012 at 10:01:17PM +0900, Yoshihiro YUNOMAE wrote:
This patch adds a ring-buffer driver for IVShmem device, a virtual RAM device
in
QEMU. This driver can be used as a ring-buffer for kernel logging or tracing
of
a guest OS by recording kernel programing or SystemTap.
This
On Thu, Aug 16, 2012 at 09:35:12AM -0400, Tomas Racek wrote:
Hi,
I am writing a file system test which I execute in qemu with kernel compiled
from latest git sources and running it causes this error:
https://bugzilla.kernel.org/show_bug.cgi?id=45971
It works with v3.5, so I ran git
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
From: Borislav Petkov b...@suse.de
The Atom core (cpu name n270 in QEMU speak) supports MOVBE. This is
needed when booting 3.8 and later linux kernels built with the MATOM
target because we require MOVBE in order to boot properly now.
Cc: H. Peter Anvin h...@zytor.com
Cc: Richard Henderson r
Hi Andreas,
On Fri, Feb 08, 2013 at 12:38:03PM +0100, Andreas Färber wrote:
Am 08.02.2013 10:30, schrieb Borislav Petkov:
From: Borislav Petkov b...@suse.de
The Atom core (cpu name n270 in QEMU speak) supports MOVBE. This is
needed when booting 3.8 and later linux kernels built
On Fri, Feb 08, 2013 at 01:19:02PM -0200, Eduardo Habkost wrote:
-machine pc-1.3 -cpu n270 (and older machine-types) needs to keep
MOVBE disabled, or you will break live migration.
Personally I wouldn't mind declaring n270 as a non-migratable CPU
model. But libvirt supports n270, so it
On Fri, Feb 08, 2013 at 01:58:58PM -0200, Eduardo Habkost wrote:
[ … ]
As we don't have a decent method to do that today, we are using static
variables and compatibility-setup functions called from the machine init
function. See disable_kvm_pv_eoi() for example.
One day we will be able to
On Fri, Feb 08, 2013 at 04:23:04PM -0200, Eduardo Habkost wrote:
If you don't have the implementation of MOVBE working (and included on
TCG_EXT_FEATURES), neither your patch or +movbe can help you.
Yes, running -cpu n270,+movbe with Richard's patchset merged works.
Thanks.
--
Regards/Gruss,
Should we perhaps CC qemu-devel here for an opinion.
Guys, this mail should explain the issue but in case there are
questions, the whole thread starts here:
http://lkml.kernel.org/r/20140407111725.GC25152@localhost
Thanks.
On Sat, Apr 12, 2014 at 01:35:49AM +0800, Jet Chen wrote:
On
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
From: Borislav Petkov b...@suse.de
Add the missing space to separate address from specified.
Cc: Anthony Liguori aligu...@amazon.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Borislav Petkov b...@suse.de
---
cpus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
as coding style differs significantly from that of
the kernel?
:-)
---
From: Borislav Petkov b...@suse.de
Subject: [PATCH] memsave: Improve and disambiguate error message
When requesting a size which cannot be read, the error message shows
a different address which is misleading to the user
On Sun, Feb 08, 2015 at 10:46:05PM +0100, Paolo Bonzini wrote:
I use :set shiftwidth=4 expandtab and c-indent mode.
Quick googling for vim four spaces suggests the following alternatives:
* :set tabstop=8 expandtab shiftwidth=4 softtabstop=4
* set tabstop=8 softtabstop=0 expandtab
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
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 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
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 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 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 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
Hi guys,
I'm using the hack below to do some quick kernel testing by setting
arbitrary feature bits and then make it execute the code for that
feature.
For example, boot with:
-cpu EPYC,cpuid-leaf=0x8007,ebx=0xf
to set some RAS feature bits and test newer RAS code.
Would something like
On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote:
> In current implementation, when -cpu ...,+sev is passed without
> appropriate SEV configuration then we populate the Fn8000_001F CPUID but
> VMCB will not have SEV bit set hence a guest will be launched as
> non-SEV.
I think we
On Tue, Feb 13, 2018 at 09:39:01AM -0600, Brijesh Singh wrote:
> Yes, I think we should be able to avoid creating new CPU model to
> handle this case. I am leaning towards dropping this patch and
> implement logic to populate the CPUID 0x8000_001F only when SEV is
> enabled. This should not
On Mon, Apr 29, 2019 at 03:01:24PM +, Singh, Brijesh wrote:
> Practically I don't see any reason why caller would do that but
> theoretically it can. If we cache the len then we also need to consider
> adding another flag to hint whether userspace ever requested length.
> e.g an application
On Fri, Apr 26, 2019 at 02:29:31PM +, Singh, Brijesh wrote:
> Yes that's doable but I am afraid that caching the value may lead us to
> wrong path and also divergence from the SEV API spec. The spec says the
> returned length is a minimum length but its possible that caller can
> give a bigger
On Wed, Apr 24, 2019 at 04:09:59PM +, Singh, Brijesh wrote:
> The command is used to create an outgoing SEV guest encryption context.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> C
On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> >
> > early console in extract_kernel
> > input_data: 0x0be073a8
> > input_len: 0x008cfc43
> > output: 0x0100
> > output_len:
On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
> Look closer at the boot process. The compressed image is initially at
> 0x10, but it gets relocated to a safer area at the end of
> startup_64:
That is the address we're executing here from, rip here looks like 0x100xxx.
>
On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> I'll attach a .config file. Apply the patch at the top of this thread to
> qemu,
Hmm, so the patch at the top of this thread is fixing the clobbering of
setup_data.
But I tried latest qemu with your .config and it boots ok
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> This needs to be something like:
>
> kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> kernel_add_identity_map(sd_addr + sizeof(*sd),
> sd_addr + sizeof(*sd) + sd->len);
It still #PFs with that:
(gdb) bt
#0
On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> Nothing special... `-kernel bzImage` should be enough to do it. Eric
> reported it, and then I was able to repro trivially. Sure you got the
> right version?
Yeah, qemu executables confusion here - had wrongly something older
On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> Are you using patch v1 minus the 62 MiB thing?
No, I want to see the original failure - the one that prompted you to send
https://lore.kernel.org/r/20221228143831.396245-1-ja...@zx2c4.com
--
Regards/Gruss,
Boris.
On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> That failure is unrelated to the ident mapping issue Peter and
> I discussed. The original failure is described in the commit message:
> decompression clobbers the data, so sd->next points to garbage.
Right, and the fact that
On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote:
> So with that understanding confirmed, I'm confused at your surprise that
> hpa's unrelated fix to the different issue didn't fix this issue.
No surprise there - I used a qemu variant without your patch to prevent the
setup_data
On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> As far as a crash... that sounds like a big and a pretty serious one at that.
>
> Could you let me know what kernel you are using and how *exactly* you are
> booting it?
Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it
On Mon, Jan 02, 2023 at 07:01:50AM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> > It would probably be a good idea to add a "maximum physical address for
> > initrd/setup_data/cmdline" field to struct kernel_info, tho
On Sat, Dec 31, 2022 at 07:21:06PM -0800, H. Peter Anvin wrote:
> As far as the decompression itself goes, it should only a problem if we are
> using physical KASLR since otherwise the kernel has a guaranteed safe zone
> already allocated by the boot loader. However, if physical KASLR is in use,
On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote:
> It would probably be a good idea to add a "maximum physical address for
> initrd/setup_data/cmdline" field to struct kernel_info, though. It appears
> right now that those fields are being identity-mapped in the decompressor,
> and
On Mon, Jan 02, 2023 at 10:32:03AM +0100, Ard Biesheuvel wrote:
> So instead of appending data to the compressed image and assuming that
> it will stay in place, create or extend a memory reservation
> elsewhere, and refer to its absolute address in setup_data.
>From my limited experience with
On Fri, Dec 02, 2022 at 02:13:40PM +0800, Chao Peng wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 1782c4555d94..7f0f5e9f2406 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1150,6 +1150,9 @@ static struct kvm *kvm_create_vm(unsigned long type,
>
On Mon, Dec 19, 2022 at 04:15:32PM +0800, Chao Peng wrote:
> Tamping down with error number a bit:
>
> if (attrs->flags)
> return -ENXIO;
> if (attrs->attributes & ~supported_attrs)
> return -EOPNOTSUPP;
> if (!PAGE_ALIGNED(attrs->address)
On Fri, Dec 02, 2022 at 02:13:41PM +0800, Chao Peng wrote:
> In memory encryption usage, guest memory may be encrypted with special
> key and can be accessed only by the guest itself. We call such memory
> private memory. It's valueless and sometimes can cause problem to allow
valueless?
I can't
On Tue, Dec 20, 2022 at 03:43:18PM +0800, Chao Peng wrote:
> RESTRICTEDMEM is needed by TDX_HOST, not TDX_GUEST.
Which basically means that RESTRICTEDMEM should simply depend on KVM.
Because you can't know upfront whether KVM will run a TDX guest or a SNP
guest and so on.
Which then means that
ub.com/ehabkost/qemu
Also, thanks for the help Eduardo! :-)
---
From: Borislav Petkov
Date: Tue, 11 Dec 2018 17:01:00 +0100
The missing functionality was added ~3 years ago with the Linux commit
46896c73c1a4 ("KVM: svm: add support for RDTSCP")
so reenable RDTSCP support on
On Wed, Dec 12, 2018 at 05:52:35PM -0200, Eduardo Habkost wrote:
> Why did you remove this entry from PC_COMPAT_2_4?
>
> We must keep compatibility with old behavior of Opteron_G2 on
> pc-2.4, even if the old behavior was incorrect.
Ok, hunk reverted. v2 below.
Thx.
---
From: Bor
65 matches
Mail list logo
