ASCII string, to help emulators (such as QEMU) load OS X when
running on genuine Apple hardware.
Signed-off-by: Gabriel L. Somlo
---
For extra context: To boot OS X as a guest, QEMU must (among others)
emulate the AppleSMC. To boot successfully, OS X insists on querying
the (emulated) SMC for the val
ASCII string, to help emulators (such as QEMU) load OS X when
running on genuine Apple hardware.
Signed-off-by: Gabriel L. Somlo
---
Henrik,
On Mon, Dec 10, 2012 at 09:19:51PM +0100, Alexander Graf wrote:
>
> On Mon, Dec 10, 2012 at 08:54:14PM +0100, Henrik Rydberg wrote:
> >
> &g
Henrik, I agree with you that it's silly to poke the hardware for a
string we KNOW will NEVER change :)
That being said, I too would love to live in a world where technical
common sense prevailed over bullshit lawyerly tactics, "corporate
strategies", and the ensuing FUD.
The way things stand tod
On Thu, Dec 13, 2012 at 08:20:11AM +0100, Henrik Rydberg wrote:
> > The only viable (from a legal CYA standpoint) thing I can think of is
> > to make it easy to acquire the OSK automatically, on demand, directly
> > from the hardware. Right now, the logical place for that is applesmc.ko.
> > It alr
On Sun, Sep 18, 2016 at 02:48:30PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 18 Sep 2016 14:43:21 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (6):
> Use kmalloc_array() in fw_cfg_register_dir_entries
On Tue, Oct 31, 2017 at 04:19:35PM +0100, Marc-André Lureau wrote:
> Add an optional kernel module (or command line) parameter
> using the following syntax:
>
> [qemu_fw_cfg.]ioport=@[::[:]]
> or
> [qemu_fw_cfg.]mmio=@[::[:]]
>
> and initializes the register address using given or d
- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -33,6 +33,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> MODULE_AUTHOR("Gabriel L. Somlo ");
> MODULE_DESCRIPTION("QEMU fw_cfg sysfs support");
>
On Tue, Oct 31, 2017 at 04:19:37PM +0100, Marc-André Lureau wrote:
> The following patch is going to use the symbol from the fw_cfg module.
>
> Signed-off-by: Marc-André Lureau
Acked-by: Gabriel Somlo
> ---
> kernel/crash_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel
On Tue, Oct 31, 2017 at 04:19:33PM +0100, Marc-André Lureau wrote:
> Hi,
>
> This series adds DMA operations support to the qemu fw_cfg kernel
> module and populates "etc/vmcoreinfo" with vmcoreinfo location
> details.
>
> Note: the support for this entry handling has been merged for next
> qemu
bd9bb134900 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -35,6 +35,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> MODULE_AUTHOR("Gabriel L. Somlo ");
> MODULE_DESCRIPTION("QEMU fw_
On Tue, Oct 31, 2017 at 04:19:34PM +0100, Marc-André Lureau wrote:
> Signed-off-by: Marc-André Lureau
Acked-by: Gabriel Somlo
> ---
> drivers/firmware/qemu_fw_cfg.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmwa
g.c
> > > index 1f3e8545dab7..8ce5e49b7c62 100644
> > > --- a/drivers/firmware/qemu_fw_cfg.c
> > > +++ b/drivers/firmware/qemu_fw_cfg.c
> > > @@ -33,6 +33,8 @@
> > > #include
> > > #include
> > > #include
> > > +
On Mon, Oct 05, 2015 at 11:00:36AM +0100, Mark Rutland wrote:
> On Sat, Oct 03, 2015 at 07:28:05PM -0400, Gabriel L. Somlo wrote:
> > From: "Gabriel Somlo"
> >
> > Allow access to QEMU firmware blobs, passed into the guest VM via
> > the fw_cfg device, throu
On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote:
> On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 05/10/2015 12:00, Mark Rutland wrote:
> > > Some of the keys in the example look like they'd come from other sources
> > > (e.g. the *-tables entries), whi
On Mon, Oct 05, 2015 at 01:50:47PM +0100, Peter Maydell wrote:
> On 5 October 2015 at 13:40, Gabriel L. Somlo wrote:
> > In addition, Michael's comment earlier in the thread suggests that
> > even my current acpi version isn't sufficiently "orthodox" w.r.t.
>
On Mon, Oct 05, 2015 at 01:56:47PM +0100, Mark Rutland wrote:
> On Mon, Oct 05, 2015 at 08:43:46AM -0400, Gabriel L. Somlo wrote:
> > On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote:
> > > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote:
> > >
On Tue, Oct 06, 2015 at 10:54:42AM -0700, Andy Lutomirski wrote:
> On Sat, Oct 3, 2015 at 4:28 PM, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Make fw_cfg entries of type "file" available via sysfs. Entries
> > are listed under /sys/firmware/qem
Hi Christopher,
On Wed, Aug 26, 2015 at 02:15:03PM -0400, Christopher Covington wrote:
> On 08/19/2015 04:49 PM, Gabriel L. Somlo wrote:
> > On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
> >> On 19 August 2015 at 11:38, Ard Biesheuvel
> >> wrote:
&g
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and
s (read-only, under "/sys/firmware/qemu_fw_cfg/...").
+ *
+ * Copyright 2015 Carnegie Mellon University
+ */
+
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw_cfg sysfs support");
+MODULE_LICENSE("G
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 3e3a5c3..bea2c9b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -842,6 +842,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
From: Gabriel Somlo
Instead of blindly probing fw_cfg registers at known IOport and MMIO
locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
device is present, and, if found, to initialize it.
This limits portability to architectures which support ACPI (x86 and
UEFI-enabled aarc
On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote:
> On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Instead of blindly probing fw_cfg registers at known IOport and MMIO
> > locations, use the ACPI sub
On Sun, Oct 04, 2015 at 04:24:00PM -0400, Gabriel L. Somlo wrote:
> On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote:
> > On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> > >
> > > Instead of blindly probing fw_cfg registe
Ping :)
On Sun, Dec 27, 2020 at 11:13:16AM -0500, Gabriel Somlo wrote:
> This series expands on commit 22447a99c97e ("drivers/soc/litex: add LiteX
> SoC Controller driver"), adding support for handling both 8- and 32-bit
> LiteX CSR (MMIO) subregisters, on both 32- and 64-bit CPUs.
>
> Notes v5:
Hi Mateusz,
On Tue, Jan 12, 2021 at 03:31:59PM +0100, Mateusz Holenko wrote:
> > Upstream LiteX now defaults to using 32-bit CSR subregisters
> > (see https://github.com/enjoy-digital/litex/commit/a2b71fde).
> >
> > This patch expands on commit 22447a99c97e ("drivers/soc/litex: add
> > LiteX SoC C
On Fri, Dec 25, 2020 at 09:21:20AM -0500, Gabriel Somlo wrote:
> Upstream LiteX now defaults to using 32-bit CSR subregisters
> (see https://github.com/enjoy-digital/litex/commit/a2b71fde).
>
> This patch expands on commit 22447a99c97e ("drivers/soc/litex: add
> LiteX SoC Controller driver"), addi
On Sun, Dec 27, 2020 at 11:13:20AM -0500, Gabriel Somlo wrote:
> The 'litex_[set|get]_reg()' methods use the 'reg_size' parameter to
> specify the width of the LiteX CSR (MMIO) register being accessed.
>
> Since 'u64' is the widest data being supported, the value of 'reg_size'
> MUST be between 1
abriel
>From 0375a0aceb54cdbc26a6c0e5b43c46324f830ec3 Mon Sep 17 00:00:00 2001
From: "Gabriel L. Somlo"
Date: Wed, 18 Jun 2014 14:39:15 -0400
Subject: [PATCH] kvm: x86: revert "emulate monitor and mwait instructions as
nop"
This reverts commit 87c00572ba05aa8c9db118da75c608f4
On Wed, Jun 18, 2014 at 11:30:07AM -0700, Eric Northup wrote:
> Quoting Gabriel's post http://www.spinics.net/lists/kvm/msg103792.html :
>
> [...]
>
> > E.g., OS X 10.5 *does* check CPUID, and panics if it doesn't find it.
> > It needs the MONITOR cpuid flag to be on, *and* the actual
> > instruc
etter off removing this hack from KVM altogether, at least for now.
Signed-off-by: Gabriel L. Somlo
Acked-by: Michael S. Tsirkin
---
OK, here's the formal proposal to revert my original monitor/mwait hack...
I wish I knew about the "idlehalt=0" before I submitted it, but such is li
Any decision on this ? If we're going to revert monitor/mwait as nop,
it's hopefully not too late to avoid having it show up in an official
(3.16 ?) kernel release...
Thanks,
--Gabriel
On Thu, Jun 19, 2014 at 09:59:35AM -0400, Gabriel L. Somlo wrote:
> This r
Hi Ard,
On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
> (missed some cc's)
>
> On 19 August 2015 at 11:38, Ard Biesheuvel wrote:
> > From: "Gabriel L. Somlo"
> >> Several different architectures supported by QEMU are set up with a
> &
On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> It acpi_acquire_global_lock() return AE_NOT_CONFIGURED then "glk" isn't
^ ^
Ifreturns
> initialized, which, if you got very unlucky, could cause a bug.
In principle I'm
On Thu, Apr 14, 2016 at 10:12:53PM +0300, Dan Carpenter wrote:
> On Thu, Apr 14, 2016 at 02:40:06PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> > > It acpi_acquire_global_lock() return AE_NOT_CONFIGURE
On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> It acpi_acquire_global_lock() return AE_NOT_CONFIGURED then "glk" isn't
> initialized, which, if you got very unlucky, could cause a bug.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/fi
On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote:
> 2016-05-26 10:32+0300, km...@yandex-team.ru:
> > From: Dmitry Bilunov
> >
> > Intel CPUs having Turbo Boost feature implement an MSR to provide a
> > control interface via rdmsr/wrmsr instructions. One could detect the
> > presence o
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
* := (optional) offset of data register
+ *
+ * e.g.:
+ * fw_cfg.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AU
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: Gabriel Somlo
Remove redundant details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the more comprehensive
fw_cfg documentation privided by
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg,
leaving the specific ARM DTB node description in pla
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
Acked-by: Rob Herring
Reviewed-by: Lasz
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
cfg.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on ov
ping ?
Also, for the corresponding patch set on the QEMU end of things,
ping on http://thread.gmane.org/gmane.comp.emulators.qemu/376321
Thanks,
--Gabriel
On Fri, Dec 04, 2015 at 10:29:02AM -0500, Gabriel L. Somlo wrote:
> Allow access to QEMU firmware blobs, passed into the guest VM via
&g
On Tue, Nov 17, 2015 at 04:14:42PM -0600, Rob Herring wrote:
> On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote:
> >
> >
> > On 15/11/2015 03:07, Rob Herring wrote:
> >> We generally don't want DT docs to depend on other kernel documentation.
> >
> > DT docs do not contain a copy of the data s
On Wed, Nov 18, 2015 at 02:04:24PM +0100, François Revol wrote:
> On 17/11/2015 23:14, Rob Herring wrote:
> > On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote:
> >>
> >>
> >> On 15/11/2015 03:07, Rob Herring wrote:
> >>> We generally don't want DT docs to depend on other kernel documentation.
On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:
> Hi Gabriel,
>
> [auto build test WARNING on v4.4-rc2]
> [also build test WARNING on next-20151123]
> [cannot apply to robh/for-next]
>
> url:
> https://github.com/0day-ci/linux/commits/Gabriel-L-Som
On Tue, Nov 24, 2015 at 10:38:18AM -0700, Eric Blake wrote:
> On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> > On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:
>
> >>
> >>drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cm
On Tue, Feb 23, 2016 at 07:07:36AM +0200, Michael S. Tsirkin wrote:
> On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wrote:
> > On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabr
On Tue, Feb 23, 2016 at 04:14:46PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 23, 2016 at 08:47:00AM -0500, Gabriel L. Somlo wrote:
> > On Tue, Feb 23, 2016 at 07:07:36AM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wro
On Wed, Mar 16, 2016 at 06:57:01PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote:
> > Allowing for the future possibility of implementing AML-based
> > (i.e., firmware-triggered) access to the QEMU fw_cfg device,
> > acquire the global ACPI lock wh
On Tue, Apr 05, 2016 at 11:54:19AM +0300, Michael S. Tsirkin wrote:
> On Thu, Mar 17, 2016 at 09:33:40AM -0400, Gabriel L. Somlo wrote:
> > On Wed, Mar 16, 2016 at 06:57:01PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote:
&g
On Sun, Apr 03, 2016 at 03:23:19PM +0300, Michael S. Tsirkin wrote:
> If platform_driver_register fails, we should
> cleanup fw_cfg_top_ko before exiting.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Gabriel Somlo
Thanks,
--Gabriel
> ---
> drivers/firmware/qemu_fw_cfg.c | 8 +++-
> 1
On Tue, Apr 05, 2016 at 11:31:27AM +0300, Michael S. Tsirkin wrote:
> Gabriel merged support for QEMU FW CFG interface, but there's apparently
> no official maintainer. It's also possible that this will grow more
> interfaces in future. I'll happily co-maintain it and handle pull
> requests togeth
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
---
Documentation/devicetree/bindings/a
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on ov
g.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
On Mon, Nov 23, 2015 at 05:35:51PM +0100, Laszlo Ersek wrote:
> On 11/23/15 16:57, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Remove fw_cfg hardware interface details from
> > Documentation/devicetree/bindings/arm/fw-cfg.txt,
> > and replace them wi
On Mon, Nov 16, 2015 at 09:38:18AM +0100, Paolo Bonzini wrote:
> On 15/11/2015 03:07, Rob Herring wrote:
> > We generally don't want DT docs to depend on other kernel documentation.
>
> DT docs do not contain a copy of the data sheets, either. There is no
> reason to say how to use the device (an
On Mon, Oct 05, 2015 at 03:18:05PM +0200, Paolo Bonzini wrote:
>
>
> On 05/10/2015 14:50, Peter Maydell wrote:
> > If you want to try to support "firmware might also be reading
> > fw_cfg at the same time as the kernel" this is a (painful)
> > problem regardless of how the kernel figures out whet
Hi Ben,
On Wed, Apr 29, 2020 at 01:21:11PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2020-04-27 at 11:13 +0200, Mateusz Holenko wrote:
> > As Gabriel Somlo suggested to me, I could still use
> > readl/writel/ioread/iowrite() standard functions providing memory
> > barriers *and* have values
On Wed, Mar 22, 2017 at 03:35:18PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 21, 2017 at 05:02:25PM -0700, Nadav Amit wrote:
> >
> > > On Mar 21, 2017, at 3:51 PM, Gabriel Somlo wrote:
> > >
> > > And I get the exact same results on the MacBookAir4,2 (which exhibits
> > > no freezing or ext
On Fri, Mar 17, 2017 at 04:03:59AM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 05:14:15PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wro
Michael,
I tested this on OS X 10.7 (Lion), the last version that doesn't check
CPUID for MWAIT support.
I used the latest kvm from git://git.kernel.org/pub/scm/virt/kvm/kvm.git
first as-is, then with your v2 MWAIT patch applied.
Single-(V)CPU guest works as expected (but then again, single-vcpu
On Wed, Mar 15, 2017 at 08:29:23PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 15, 2017 at 02:14:26PM -0400, Gabriel L. Somlo wrote:
> > Michael,
> >
> > I tested this on OS X 10.7 (Lion), the last version that doesn't check
> > CPUID for MWAIT support.
> &g
failed
make[1]: *** [arch/x86/kvm] Error 2
Makefile:1002: recipe for target 'arch/x86' failed
make: *** [arch/x86] Error 2
Did you accidentally leave out something that went into a .h file
somewhere ?
Thx,
--G
On Wed, Mar 15, 2017 at 09:29:57PM +0200, Michael S. Tsirkin wrote:
> On
On Wed, Mar 15, 2017 at 04:21:41PM -0400, Gabriel L. Somlo wrote:
> >
> > - do you see VM exits on the "hung" VCPU?
>
> how would I go about looking ?
>
> > - what is your CPU model?
>
> $ cat /proc/cpuinfo
> ...
> processor : 3
>
apability. Add a flag in the hypervisor leaf instead.
> >
> > Additionally, we add a capability for QEMU - e.g. if it knows there's an
> > isolated CPU dedicated for the VCPU it can set the standard MWAIT flag
> > to improve guest behaviour.
> >
> &g
On Wed, Mar 15, 2017 at 09:46:18PM +0100, Radim Krčmář wrote:
> 2017-03-15 16:21-0400, Gabriel L. Somlo:
> > On Wed, Mar 15, 2017 at 09:13:49PM +0100, Radim Krčmář wrote:
> >> 2017-03-15 21:28+0200, Michael S. Tsirkin:
> >> > Guests running Mac OS 5, 6, and 7 (Leopar
taying inside L1 and
running guest-mode MWAIT in a tight loop will actually waste the host
CPU without the opportunity to yield to some other L0 thread. Sorry if
I fell into the middle of an ongoing conversation on this and missed
most of the relevant context, in which case please feel free to ig
On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> > On Wed, Mar 15, 2017 at 11:22:18PM +0200, Michael S. Tsirkin wrote:
> > > Guests running Mac OS 5, 6, and 7 (Leopard through Li
On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote:
> > After studying your patch a bit more carefully (sorry, it's crazy
> > around here right now :) ) I realized you're simply trying to
On Thu, Mar 16, 2017 at 03:08:07PM +0100, Radim Krčmář wrote:
> 2017-03-16 09:24-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> > > > On Wed, Ma
On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote:
> > > > After
On Thu, Mar 16, 2017 at 04:54:06PM +0100, Radim Krčmář wrote:
> 2017-03-16 11:44-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 03:08:07PM +0100, Radim Krčmář wrote:
> >> 2017-03-16 09:24-0400, Gabriel L. Somlo:
> >> > On Thu, Mar 16, 2017 at 01:41:28AM +
On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> 2017-03-16 16:35+0100, Radim Krčmář:
> > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> >> The intel manual said the same thing back in 2010 as well. However,
> >> regardless of how any flags were set, inte
On Thu, Mar 16, 2017 at 06:45:02PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > > > On Thu, Ma
On Thu, Mar 16, 2017 at 12:52:32PM -0400, Gabriel L. Somlo wrote:
> On Thu, Mar 16, 2017 at 06:45:02PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> &
On Thu, Mar 16, 2017 at 06:22:44PM +0100, Radim Krčmář wrote:
> 2017-03-16 12:47-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 16:35+0100, Radim Krčmář:
> > > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
>
On Thu, Mar 16, 2017 at 07:27:34PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 12:47:50PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 16:35+0100, Radim Krčmář:
> > > > 2017-03-1
On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
> Let's take a step back and try to figure out how is
> mwait called. How about dumping code of VCPUs
> around mwait? gdb disa command will do this.
Started guest with '-s', tried to attach from gdb with
"target remote localhost:
On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
> > > Let's take a step back and try to figure out how is
> &
On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote:
> On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
On Fri, Mar 10, 2017 at 12:29:31AM +0200, Michael S. Tsirkin wrote:
> Some guests call mwait without checking the cpu flags. We currently
> emulate that as a NOP but on VMX we can do better: let guest stop the
> CPU until timer or IPI. CPU will be busy but that isn't any worse than
> a NOP emulat
On Sun, Mar 12, 2017 at 02:01:32AM +0200, Michael S. Tsirkin wrote:
> On Fri, Mar 10, 2017 at 03:46:45PM -0800, Jim Mattson wrote:
> > On Thu, Mar 9, 2017 at 2:29 PM, Michael S. Tsirkin wrote:
> > > Some guests call mwait without checking the cpu flags. We currently
> >
> > "Some guests"? What g
within guests is not the same as on real hardware
> because halt causes an exit while mwait doesn't. For this reason it
> might not be a good idea to use the regular MWAIT flag in CPUID to
> signal this capability: halt is sometimes better as you are giving up
> the rest of your CPU
On Sun, Feb 21, 2016 at 03:10:30PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> >
> > >
> > > > +#if !(defined(FW_CFG_CTRL_OFF) && defined(FW_CTRL_DATA_OFF))
> > > > +# if (defined(CONFIG
On Sun, Feb 21, 2016 at 10:30:26AM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 28, 2016 at 09:23:11AM -0500, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Make fw_cfg entries of type "file" available via sysfs. Entries
> > are listed under
On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > +static void fw_cfg_io_cleanup(void)
> > > > +{
> > > > + if (fw_cfg_is_mmio) {
> >
On Thu, Feb 11, 2016 at 12:19:03PM +0100, Valentin Rothberg wrote:
> s/FW_CTRL_DATA_OFF/FW_CFG_DATA_OFF/
Thanks for catching that !
Acked-by: Gabriel Somlo
>
> Signed-off-by: Valentin Rothberg
> Signed-off-by: Andreas Ziegler
> ---
> v2: corrected typo in signed-off-by
>
> drivers/firmwar
On Thu, Feb 11, 2016 at 03:23:51PM +0100, Arnd Bergmann wrote:
> Not all machines have PCI style I/O port memory, or they do not allow
> mapping it using the ioport_map() function, whcih results in a
> build error with the newly added qemu firmware code:
>
> drivers/firmware/built-in.o: In functio
On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
> On 19 August 2015 at 22:49, Gabriel L. Somlo wrote:
> >> > From: "Gabriel L. Somlo"
> >> >> Several different architectures supported by QEMU are set up with a
> >> >>
From: "Gabriel Somlo"
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 3e3a5c3..f9754a0 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -1058,3 +1058,4 @@ EXPORT_SYMBOL(kobject_del);
EXPORT_SYMBOL(kset_re
1 - 100 of 139 matches
Mail list logo
