Signed-off-by: Gabriel Somlo
---
hw/i386/smbios.c | 10 --
qemu-options.hx | 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index f2e9ab6..1341e02 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -91,6 +91,7 @@ static s
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
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
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
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 Thu, Jun 05, 2014 at 01:59:17PM -0700, Eric Northup wrote:
> On Wed, May 7, 2014 at 1:52 PM, Gabriel L. Somlo wrote:
> > Treat monitor and mwait instructions as nop, which is architecturally
> > correct (but inefficient) behavior. We do this to prevent misbehaving
> > gues
On Wed, Jun 04, 2014 at 11:01:50PM +0300, Nadav Amit wrote:
> On Jun 4, 2014, at 10:43 PM, Gabriel L. Somlo wrote:
>
> My implementation still emulates the instruction as a NOP, but first checks
> for an exception.
[...]
> Anyhow, if you want a real mwait emulation, you can wr
On Wed, Jun 04, 2014 at 10:12:39PM +0300, Nadav Amit wrote:
> Regardless to the whole discussion of what the guest is informed about, I
> think it might be better to implement mwait and monitor correctly according
> to the spec and let the instructions to be fully emulated.
> Both mwait and monit
On Wed, Jun 04, 2014 at 10:08:12PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote:
> > Il 04/06/2014 16:44, Alexander Graf ha scritto:
> > >
> > >
> > >>Obviously, if you really like the current behavior better you can
> > >>always reject whatever p
On Wed, Jun 04, 2014 at 10:06:18PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 04, 2014 at 01:07:21PM -0400, Gabriel L. Somlo wrote:
> > Ah, so kvm_vcpu_ioctl_set_cpuid() and friends, morally similar to
> > kvm_vcpu_ioctl_enable_cap() on ppc, except it turns on cpuid flags
> &
On Wed, Jun 04, 2014 at 05:09:49PM +0200, Alexander Graf wrote:
> >>>
> >>>I grep-ed through the kvm sources for KVM_CAP for some inspiration,
> >>>and it looks more like KVM_CAP_* is a way to tell userspace what the
> >>>kernel supports, but nothing I saw showed me an example of a "tunable"
> >>>f
On Wed, Jun 04, 2014 at 04:44:13PM +0200, Alexander Graf wrote:
>
> On 04.06.14 16:39, Gabriel L. Somlo wrote:
> >Paolo,
> >
> >I noticed the monitor=mwait=nop patch is making its way upstream, so
> >thanks !
> >
> >I'm still interested in follow
e what it would look like :)
Thanks,
--Gabriel
On Tue, Jun 03, 2014 at 11:17:48AM +0200, Paolo Bonzini wrote:
> Il 02/06/2014 21:25, Gabriel L. Somlo ha scritto:
> >Would it make sense to make this a module parameter,
> >(e.g., "int emulate_mwait") ?
> >
> >Default
On Tue, Jun 03, 2014 at 05:37:08PM +0200, Alexander Graf wrote:
> On 06/03/2014 04:21 PM, Gabriel L. Somlo wrote:
> >On Tue, Jun 03, 2014 at 11:17:48AM +0200, Paolo Bonzini wrote:
> >>I think it's fine as it is now. :)
> >On Mon, Jun 02, 2014 at 09:55:18PM -0400, Gabr
On Tue, Jun 03, 2014 at 11:17:48AM +0200, Paolo Bonzini wrote:
>
> I think it's fine as it is now. :)
On Mon, Jun 02, 2014 at 09:55:18PM -0400, Gabriel L. Somlo wrote:
>
> W.r.t. monitor/mwait, a guest can do one of the following:
>
> 1. Never check CPUID, and
.06.2014 um 22:20 schrieb "Michael S. Tsirkin" :
> >>>>
> >>>> On Mon, Jun 02, 2014 at 09:48:19PM +0200, Alexander Graf wrote:
> >>>>
> >>>>
> >>>>>> Am 02.06.2014 um 21:25 schrieb "Gabriel L. Somlo&
On Wed, May 07, 2014 at 04:52:13PM -0400, Gabriel L. Somlo wrote:
> Treat monitor and mwait instructions as nop, which is architecturally
> correct (but inefficient) behavior. We do this to prevent misbehaving
> guests (e.g. OS X <= 10.7) from crashing after they fail to check for
>
nop-emulated instructions
would keep the host CPU pegged at 100%, do NOT advertise their presence
via cpuid, to prevent compliant guests from using them inadvertently.
Signed-off-by: Gabriel L. Somlo
---
New in v2: remove invalid_op handler functions which were only used to
handle ex
ops relying on these nop-emulated instructions
would keep the host CPU pegged at 100%, do NOT advertise their presence
via cpuid, preventing compliant guests from ever using them inadvertently.
Signed-off-by: Gabriel L. Somlo
---
On Wed, May 07, 2014 at 05:30:47PM +0200, Paolo Bonzini wrote:
>
On Wed, May 07, 2014 at 08:29:19AM +0200, Jan Kiszka wrote:
> On 2014-05-06 20:35, gso...@gmail.com wrote:
> > Signed-off-by: Gabriel Somlo
> > ---
> >
> > Jan,
> >
> > After today's pull from kvm, I also need this to build against my
> > Fedora 20 kernel (3.13.10-200.fc20.x86_64).
>
> Which ve
On Tue, Apr 22, 2014 at 04:57:32PM +0200, Jan Kiszka wrote:
> On 2014-04-22 16:52, gso...@gmail.com wrote:
> > Signed-off-by: Gabriel Somlo
> > ---
> >
> > vfio.c gets copied by sync, and it needs vfio.h. I don't think there's
> > an easy way to #define ourselves out of this one, copying vfio.h i
Signed-off-by: Gabriel Somlo
---
Jan,
Apparently this is needed to build the latest kvm git on 3.13 kernels
(e.g., Fedora 20, in my case).
Thanks,
Gabriel
x86/external-module-compat.h | 4
1 file changed, 4 insertions(+)
diff --git a/x86/external-module-compat.h b/x86/external-module-
On Thu, Mar 13, 2014 at 11:53:04AM +0100, Paolo Bonzini wrote:
> Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl:
>
> +On real hardware, interrupt pins can be active-low or active-high. This
> +does not matter for the level field of struct kvm_irq_level: 1 always
> +means acti
hen
interfacing with KVM.
This patch modifies KVM to completely ignore ioapic polarity as set by
the guest OS, enabling misbehaving guests to work alongside those which
comply with the ActiveHigh polarity specified by QEMU's ACPI tables.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: G
On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> >On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> >>apic polarity in KVM does not work: too many things assume active high.
> >>
g anyway.
>
> Also report this to userspace: this makes it
> possible to report the interrupt active-low
> in ACPI, this way we are closer to real hardware.
>
> This patch fixes OSX running on KVM.
>
> Reported-by: "Gabriel L. Somlo"
> Signed-off-by: Michael S
On Mon, Feb 17, 2014 at 02:38:09PM -0500, Gabriel L. Somlo wrote:
> Oh, I think I'm starting to comprehend the problem here. The bits of
> "*irq_state" are indexed by "irq_source_id", which is dynamically
> assigned by kvm_request_irq_source_id().
>
> So,
On Mon, Feb 17, 2014 at 07:06:11PM +0100, Paolo Bonzini wrote:
> Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> >On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> >>On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> >>>Wel
On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> Well there is a bigger issue: any interrupt with
> multiple sources is broken.
>
> __kvm_irq_line_state does a logical OR of all sources,
> before XOR with polarity.
>
> This makes no sense if polarity is active low.
So, do yo
On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> > Well there is a bigger issue: any interrupt with
> > multiple sources is broken.
> >
> > __kvm_irq_line_state does a logical OR
On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
>
> Can't you just turn the polarity around in the pci host adapter?
I tried this:
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 1221f32..0e86d21 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -118,13 +118,13 @@ static int pci_bar
On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > anyone have experience with any *other* guests which insist on se
On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > I'm trying to get OS X to work as a QEMU guest, and one of the few
> > remaining "mysteries" I need to solve is that the OS
Hi,
I'm trying to get OS X to work as a QEMU guest, and one of the few
remaining "mysteries" I need to solve is that the OS X guest hangs
during boot, waiting for its boot disk to be available, unless the
following KVM patch is applied:
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce
On Fri, Dec 13, 2013 at 04:36:07PM +0100, Jan Kiszka wrote:
> On 2013-12-13 16:12, Paolo Bonzini wrote:
>> I think the relevance of releases is ~zero. kvm-kmod still remains
>> extremely useful IMHO as a hacking tool.
>
> Exactly.
I agree. No idea how "Real KVM Hackers (tm)" do it, but this wann
Jan,
After upgrading my F18 box to 3.11.10-100.fc18.x86_64 I noticed the
"version fence" on kvm-kmod is set to 3.10, and that the current
"source link" for the kvm subproject is set to commit
bf640876e21fe603f7f52b0c27d66b7716da0384
After some testing, kvm-kmod works fine without any changes bey
Peter,
On Tue, Nov 12, 2013 at 02:57:36PM +, Peter Maydell wrote:
> Can somebody provide known-good instructions for how to
> sign and return keys? I looked on the web and found four
> different possible ways to do this (most notably, there
> seems to be a split between "just send keys back to
On Mon, Apr 29, 2013 at 10:41:36PM +0200, Jan Kiszka wrote:
> On 2013-04-29 22:39, Gabriel L. Somlo wrote:
> > On Mon, Apr 29, 2013 at 10:33:29PM +0200, Jan Kiszka wrote:
> >> I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your
> >> external kvm dir
On Mon, Apr 29, 2013 at 10:33:29PM +0200, Jan Kiszka wrote:
> I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your
> external kvm directory is not recent enough.
That's weird, I just did a
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
literally five minutes ago
On Mon, Apr 29, 2013 at 10:09:42PM +0200, Jan Kiszka wrote:
> On 2013-04-29 21:44, Gabriel L. Somlo wrote:
> > On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote:
> >>> Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417
> Linking should work as wel
On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote:
> > Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417
>
> That commit alone is broken as it depends on the refactorings being
> selected by the submodule update.
>
> Does the problem persist with current master checked out
Jan,
Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417
to kvm-kmod is what causes breakage on my (otherwise stock) F18 box
(with kernel version 3.8.9-200.fc18.x86_64):
make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` clean
make[1]: Entering directory `/usr/src/kernels/3.8.9
Works great now, thanks !
--Gabriel
On Mon, Mar 11, 2013 at 05:30:45PM +0100, Jan Kiszka wrote:
> On 2013-03-07 23:00, Gabriel L. Somlo wrote:
> >
> > I'm trying to use your kvm-kmod git repo to build KVM git master
> > against the latest two Fedora 18 kernels (3.7.9-2
Hi Jan,
I'm trying to use your kvm-kmod git repo to build KVM git master
against the latest two Fedora 18 kernels (3.7.9-205 and 3.8.1-201),
and I'm running into a bit of trouble:
$ ./configure --kerneldir=/lib/modules/3.7.9-205.fc18.x86_64/build
$ make sync
$ make
make -C /lib/modules/3.7.9-20
44 matches
Mail list logo
