On Thu, 2020-07-09 at 11:44 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > (CCing libvir-list, and people who were included in the OVMF
> > > thread[1])
> > >
> > > [1]
> > > https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
> > > Also, it's important that we
This adds the KVM_CAP_HAS_SMALLER_MAXPHYADDR capability
and a helper function to check for this capability.
This will allow QEMU to decide to what to do if the host
CPU can't handle GUEST_MAXPHYADDR < HOST_MAXPHYADDR properly.
Signed-off-by: Mohammed Gamal
---
linux-headers/linux/kvm.h
If the CPU doesn't support GUEST_MAXPHYADDR < HOST_MAXPHYADDR we
let QEMU choose to use the host MAXPHYADDR and print a warning to the
user.
Signed-off-by: Mohammed Gamal
---
target/i386/cpu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cp
hen setting vCPU physical bits, and if the CPU doesn't support
KVM_CAP_HAS_SMALLER_MAXPHYADDR the ,phys-bits is ignore and host phyiscal
bits are used. A warning message is printed to the user.
Mohammed Gamal (2):
kvm: Add support for KVM_CAP_HAS_SMALLER_MAXPHYADDR
x86/cpu: Handle GUEST_MAXPHYA
Fixed by commit 528f449f590829b53ea01ed91817a695b540421d
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1673130
Title:
qemu 2.7.0 receives
Fixed by commit 528f449f590829b53ea01ed91817a695b540421d
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1671876
Title:
qemu 2.7.0 segfaults
() to the generic x86_iommu_realize() and
adds a check for PCI bus presence.
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 13 ++---
hw/i386/intel_iommu.c | 13 ++---
hw/i386/x86
.
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iom
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
h
.
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iom
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
h
x86_iommu_realize() and
adds a check for PCI bus presence.
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 13 ++---
hw/i386/intel_iommu.c | 13 ++---
hw/i386/x86-iommu.c | 13 +
3 files
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 13 ++---
hw/i386/intel_iommu.c | 13 ++---
hw/i386/x86-iommu.c
.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 51de519..8a01a2d 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ stati
x86_iommu_realize() and
adds a check for PCI bus presence.
v4 --> v5:
* Squash patch 2/3 from v4 into patch 1/3
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 13 ++---
hw/i386/intel_iommu.c |
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/x86-iommu.c
.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 51de519..8a01a2d 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ stati
Now that the calling x86_iommu_realize() calls object_dynamic_cast(),
doing the cast in amdvi_realize() and vtd_realize() is not needed.
Use PC_MACHINE macro directly.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 3 +--
hw/i386/intel_iommu.c | 3 +--
2
x86_iommu_realize() and
adds a check for PCI bus presence.
v3 --> v4:
* Restore correct object_dynamic_cast() in x86_iommu_realize()
* Remove redundant casting in callee functions. Implemented in
a new patch
Mohammed Gamal (3):
x86_iommu: Move machine check to x86_iommu_realize()
intel_io
On Mon, 2017-09-18 at 10:13 -0300, Eduardo Habkost wrote:
> On Mon, Sep 18, 2017 at 12:14:08PM +0200, Mohammed Gamal wrote:
> > Instead of having the same error checks in vtd_realize()
> > and amdvi_realize(), move that over to the generic
> > x86_iommu_realize().
> >
.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index d43b08a..00f70bb 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -87,7 +87,7 @@ stati
x86_iommu_realize() and
adds a check for PCI bus presence.
v2 --> v3:
* Use PC_MACHINE macro directly
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/x86-iommu.c
x86_iommu_realize() and
adds a check for PCI bus presence.
v1 --> v2:
* Change error message with capitalized acronym
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c |
.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 51de519..8a01a2d 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ stati
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/x86-iommu.c
.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/x86-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 4d17e1f..afd8cd9 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ stati
x86_iommu_realize() and
adds a check for PCI bus presence.
Mohammed Gamal (2):
x86_iommu: Move machine check to x86_iommu_realize()
x86_iommu: check if machine has PCI bus
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/x86-iommu.c | 13 +
3 files changed
Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 10 +-
hw/i386/intel_iommu.c | 10 +-
hw/i386/x86-iommu.c
On Fri, 2017-09-15 at 10:07 +0800, Peter Xu wrote:
> On Thu, Sep 14, 2017 at 05:31:38PM -0300, Eduardo Habkost wrote:
> > On Thu, Sep 14, 2017 at 10:24:23PM +0200, Thomas Huth wrote:
> > > On 14.09.2017 22:18, Mohammed Gamal wrote:
> > > > Starting the following
access. AMD IOMMU shouldn't even work
if the target machine doesn't have PCI.
Add a check for PCI on the given machine type and return an error if PCI
is not supported.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 7 +++
1 file changed, 7 insertions(+)
diff
access. AMD IOMMU shouldn't even work
if the target machine doesn't have PCI.
Add a check for PCI on the given machine type and return an error if PCI
is not supported.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/amd_iommu.c | 7 +++
1 file changed, 7 insertions(+)
diff
-pointer access. Intel IOMMU shouldn't even work
if the target machine doesn't have PCI.
Add a check for PCI on the given machine type and return an error if PCI
is not supported.
Signed-off-by: Mohammed Gamal <mga...@redhat.com>
---
hw/i386/intel_iommu.c | 7 +++
1 file changed, 7 inse
Another stack trace:
--
(gdb) bt
#0 0x7f2f34690067 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x7f2f34691448 in __GI_abort () at abort.c:89
#2 0x5629b8260b6c in
Third stack trace:
--
#0 0x7f4d5ad6a067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7f4d5ad6b448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x562a4c582b6c in qemu_coroutine_enter
Public bug reported:
I've been experiencing frequent SIGABRTs (in addition to segfaults in
#1671876) lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash
usually happens in qemu_coroutine_enter(). I haven't seen this so far
with any other guests or distros.
Here is one stack trace I
Unfortunately it'd not be possible to use another version at the moment.
Is it possible that someone takes a look at the stack traces?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1671876
Title:
** Description changed:
Hi,
I've been experiencing frequent segfaults lately with qemu 2.7.0 running
Ubuntu 16.04 guests. The crash usually happens in
qemu_co_queue_run_restart(). I haven't seen this so far with any other
guests or distros.
Here is one back trace I obtained from
The VMs were running with the following arguments
-
-m 1024,slots=255,maxmem=256G -M pc-i440fx-2.7 -enable-kvm -nodefconfig
-nodefaults -rtc base=utc -netdev
A third stack trace
It generates the following stack trace
-
(gdb) bt
#0 qemu_co_queue_run_restart (co=0x7f75ed30dbc0) at
/build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59
#1 0x5619274829a9 in
Public bug reported:
Hi,
I've been experiencing frequent segfaults lately with qemu 2.7.0 running
Ubuntu 16.04 guests. The crash usually happens in
qemu_co_queue_run_restart(). I haven't seen this so far with any other
guests or distros.
Here is one back trace I obtained from one of the
Another stack trace
-
(gdb) bt
#0 qemu_co_queue_run_restart (co=0x7f668be15260) at
/build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59
#1 0x564cb19f59a9 in qemu_coroutine_enter (co=0x7f668be15260) at
Please drop this patch. I see it has already been fixed upstream
On Tue, Jun 21, 2016 at 11:10 AM, Mohammed Gamal
<mohammed.ga...@profitbricks.com> wrote:
> The configure script contains an embedded test C function
> to test for avx2 support. It gets optimized away with
> gcc 4.7 o
The configure script contains an embedded test C function
to test for avx2 support. It gets optimized away with
gcc 4.7 on wheezy.
Add __attribute__((optimize("O0"))) to it in order
to prevent optimizing it away
Signed-off-by: Mohammed Gamal <mohammed.ga...@profitbricks.com>
--
Any ideas?
On Thu, Mar 17, 2016 at 4:19 PM, Mohammed Gamal <m.gamal...@gmail.com> wrote:
> Hi All,
>
> I have a question regarding the way CPU topology is exposed to the guest.
>
> On a 4-core Amazon AWS VM I can see the CPU topology exposed to the
> guest in the follow
Hi All,
I have a question regarding the way CPU topology is exposed to the guest.
On a 4-core Amazon AWS VM I can see the CPU topology exposed to the
guest in the following manner:
# lstopo
Machine (7480MB)
Socket L#0 + L3 L#0 (25MB)
L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core
On Wed, Mar 18, 2015 at 7:09 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Wed, Mar 18, 2015 at 06:36:48PM +0100, Mohammed Gamal wrote:
Hi,
I've been sporadically getting my KVM virtual machines crashing with this
message while they're booting
KVM internal error. Suberror: 1
Hi,
I've been sporadically getting my KVM virtual machines crashing with this
message while they're booting
KVM internal error. Suberror: 1
emulation failure
EAX= EBX= ECX= EDX=00600f12
ESI= EDI= EBP= ESP=fffa
EIP=ff53 EFL=0006 [-P-]
Ping.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297218
Title:
guest hangs after live migration due to tsc jump
Status in QEMU:
New
Status in glusterfs package in Ubuntu:
Invalid
Status
Hi Serge,
Yes, that's the case. Let me also make it clear that this is a backport on top
of qemu 1.2 stable.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297218
Title:
guest hangs after live
On Fri, Jan 16, 2015 at 11:21 AM, Mohammed Gamal
mohammed.ga...@profitbricks.com wrote:
On Thu, Jan 15, 2015 at 06:27:54PM +0100, Paolo Bonzini wrote:
On 15/01/2015 17:39, Mohammed Gamal wrote:
The increase in the jitter and offset values is well within the 500 ppm
frequency
Hi,
I've seen some strange time behavior in some of our VMs usually
triggered by live migration. In some VMs we have seen some significant
time drift which NTP was not able to correct after doing a live
migration.
I've not been able so far to reproduce the same case, however, I did
notice that
On Thu, Jan 15, 2015 at 06:27:54PM +0100, Paolo Bonzini wrote:
On 15/01/2015 17:39, Mohammed Gamal wrote:
The increase in the jitter and offset values is well within the 500 ppm
frequency tolerance limit, and therefore are easily corrected by
subsequent NTP clock sync events, but some
Hi,
I've seen some strange time behavior in some of our VMs usually triggered
by live migration. In some VMs we have seen some significant time drift
which NTP was not able to correct after doing a live migration.
I've not been able so far to reproduce the same case, however, I did notice
that
Hi,
We are experiencing random errors with communication with VMs with QMP via
unix sockets. At some moment of time the QMP socket keeps on returning
-EAGAIN and never recovering from this state unless the qemu process is
stopped then started. This socket hickup happens specfically when
Hi,
QMP command 'query-memory-devices' returns DIMM slots IDs as integers,
while 'query-acpi-ospm-status' returns them as strings. Why is this the
case? Aren't slot IDs numeric anyway?
I've looked up the ACPI specs but I can't find any specific mention of how
DIMM IDs should be represented, so
On Thu, May 20, 2010 at 12:44 PM, Andre Przywara andre.przyw...@amd.com wrote:
Is that still a problem? What was the exact error?
I quickly tried the 3.1.2a on qemu 0.12.4 (with and without KVM) and I could
easily login.
This happens with MINIX 3.1.6, during boot it briefly goes into an
On Tue, May 11, 2010 at 11:56 PM, Andy Walls awa...@md.metrocast.net wrote:
Running an MS-DOS 6.22 image with qemu-kvm on a RedHat Linux OS, I
noticed the guest OS becomes hung and my dmesg gets spammed with
set_cr0: #GP, set PG flag with a clear PE flag
That message appears to be the
On Tue, Apr 20, 2010 at 8:36 PM, jvrao jv...@linux.vnet.ibm.com wrote:
... snip ...
This'd be something interesting to do. I wonder if that would fit in
the GSoC timeframe, or whether it'd be a little too short. So how long
you'd estimate something like that would take?
I think it would
On Tue, Apr 20, 2010 at 12:54 AM, jvrao jv...@linux.vnet.ibm.com wrote:
Mohammed Gamal wrote:
On Tue, Apr 13, 2010 at 9:08 PM, jvrao jv...@linux.vnet.ibm.com wrote:
jvrao wrote:
Alexander Graf wrote:
On 12.04.2010, at 13:58, Jamie Lokier wrote:
Mohammed Gamal wrote:
On Mon, Apr 12, 2010
On Tue, Apr 13, 2010 at 9:08 PM, jvrao jv...@linux.vnet.ibm.com wrote:
jvrao wrote:
Alexander Graf wrote:
On 12.04.2010, at 13:58, Jamie Lokier wrote:
Mohammed Gamal wrote:
On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier ja...@shareable.org
wrote:
Javier Guerra Giraldez wrote:
On Sat, Apr
On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier ja...@shareable.org wrote:
Javier Guerra Giraldez wrote:
On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal m.gamal...@gmail.com wrote:
On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier ja...@shareable.org wrote:
To throw a spanner in, the most widely
On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier ja...@shareable.org wrote:
Mohammed Gamal wrote:
Hi Javier,
Thanks for the link. However, I'm still concerned with
interoperability with other operating systems, including non-Windows
ones. I am not sure of how many operating systems actually
On Fri, Apr 9, 2010 at 7:11 PM, jvrao jv...@linux.vnet.ibm.com wrote:
Luiz Capitulino wrote:
On Thu, 8 Apr 2010 18:01:01 +0200
Mohammed Gamal m.gamal...@gmail.com wrote:
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving
On Fri, Apr 9, 2010 at 11:22 PM, Jamie Lokier ja...@shareable.org wrote:
Mohammed Gamal wrote:
2- With respect to CIFS. I wonder how the shares are supposed to be
exposed to the guest. Should the Samba server be modified to be able
to use unix domain sockets instead of TCP ports and then QEMU
On Sat, Apr 10, 2010 at 12:22 AM, Javier Guerra Giraldez
jav...@guerrag.com wrote:
On Fri, Apr 9, 2010 at 5:17 PM, Mohammed Gamal m.gamal...@gmail.com wrote:
That's all good and well. The question now is which direction would
the community prefer to go. Would everyone be just happy with
virtio
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving the pass-though
filesystems.
I've got some questions on that:
1- What does the community prefer to use and improve? CIFS, 9p, or
both? And which is better taken up for GSoC.
2-
On Thu, Apr 8, 2010 at 6:01 PM, Mohammed Gamal m.gamal...@gmail.com wrote:
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving the pass-though
filesystems.
I've got some questions on that:
1- What does the community prefer
On Sat, Mar 20, 2010 at 3:18 PM, Avi Kivity a...@redhat.com wrote:
On 03/20/2010 10:55 AM, Alexander Graf wrote:
I'd say that a GSoC project would rather focus on making a guest OS work
than working on generic big real mode. Having Windows 98 support is way
more
visible to the users. And
Hello all,
As some of you might know, I've worked on supporting big real mode
emulation on VMX back in GSoC 2008. Looking at the Qemu GSoC ideas
list for this year, I found it among the possible ideas for a GSoC
project. I'd be interested in driving this feature towards completion,
and I have a
70 matches
Mail list logo
