On Thu 21 Mar 2019 09:30:26 AM CET, Vladimir Sementsov-Ogievskiy wrote:
> 20.03.2019 20:25, Alberto Garcia wrote:
>> On Wed 20 Mar 2019 10:35:27 AM CET, Vladimir Sementsov-Ogievskiy wrote:
Maybe at least this kind of freezing isn't the right tool for block
jobs, after all.
>>>
>>> I think
When virtio-vga was added, the intention was to only support it for
those machines where the firmware does not know about virtio-gpu,
and supported VGA legacy hardware before virtio-{gpu,vga} were
introduced.
The Kconfig switch however enabled virtio-vga for all machines with
a PCI bus, and libvir
On Thu, 21 Mar 2019, Igor Mammedov wrote:
On Tue, 19 Mar 2019 23:47:22 +0100 (CET)
BALATON Zoltan wrote:
On Tue, 19 Mar 2019, Igor Mammedov wrote:
On Sun, 17 Mar 2019 01:22:57 +0100
Philippe Mathieu-Daudé wrote:
The PIIX4 chipset is a generic southbridge and can be used by
non-X86 hardware
On 21/03/19 14:04, Peter Maydell wrote:
>>
>> were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
>> dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
>> Express dependencies of 'pseries' and 'powernv' machines with kconfig",
>> 2019-03-07), from files
>>
>>
On 03/19/2019 09:47 AM, Alex Bennée wrote:
This is an inverse selection which excludes a selected set of targets
from the default target list. It will mostly be useful for CI
configurations but it might be useful for some users as well.
You cannot specify --target-list and --target-list-exclud
These changes provide the interface with the KVM device implementing
the XIVE native exploitation interrupt mode. Also used to retrieve the
state of the KVM device for the monitor usage and for migration.
Available from :
https://github.com/legoater/linux/commits/xive-5.1
Signed-off-by: Cédric
ello,
This is the v3 of the QEMU/KVM patchset taking into account the
remarks on v2 and the remarks on the Linux/KVM interface.
The first patches introduce the XIVE KVM device, state synchronization
and migration support under KVM. The second part of the patchset
modifies the XICS and XIVE interr
This will be used to remove the MMIO regions of the POWER9 XIVE
interrupt controller when the sPAPR machine is reseted.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
---
include/hw/sysbus.h | 1 +
hw/core/sysbus.c| 10 ++
2 files changed, 11 insertions(+)
diff --git a/
This handler is in charge of stabilizing the flow of event notifications
in the XIVE controller before migrating a guest. This is a requirement
before transferring the guest EQ pages to a destination.
When the VM is stopped, the handler sets the source PQs to PENDING to
stop the flow of events and
Removing RTAS handlers will become necessary when the new pseries
machine supporting multiple interrupt mode is introduced.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr.h | 4
hw/ppc/spapr_rtas.c| 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/hw
If a new interrupt mode is chosen by CAS, the machine generates a
reset to reconfigure. At this point, the connection with the previous
KVM device needs to be closed and a new connection needs to opened
with the KVM device operating the chosen interrupt mode.
New routines are introduced to destroy
This introduces a set of helpers when KVM is in use, which create the
KVM XIVE device, initialize the interrupt sources at a KVM level and
connect the interrupt presenters to the vCPU.
They also handle the initialization of the TIMA and the source ESB
memory regions of the controller. These have a
All is in place for KVM now. State synchronization and migration will
come next.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
---
hw/ppc/spapr_irq.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index f6db48b4da79..b4e3128b7f06
This extends the KVM XIVE device backend with 'synchronize_state'
methods used to retrieve the state from KVM. The HW state of the
sources, the KVM device and the thread interrupt contexts are
collected for the monitor usage and also migration.
These get operations rely on their KVM counterpart in
The activation of the KVM IRQ device depends on the interrupt mode
chosen at CAS time by the machine and some methods used at reset or by
the migration need to be protected.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
---
Changes since v2:
- did an update in ics_set_kvm_state_o
When the VM is stopped, the VM state handler stabilizes the XIVE IC
and marks the EQ pages dirty. These are then transferred to destination
before the transfer of the device vmstates starts.
The SpaprXive interrupt controller model captures the XIVE internal
tables, EAT and ENDT and the XiveTCTX m
On Thu 21 Mar 2019 03:53:41 PM CET, Kevin Wolf wrote:
>> >>> I think, the correct way, which will support these correct cases
>> >>> (which however don't look like real use cases) is removing base
>> >>> from stream view. Stream should operate instead using
>> >>> bottom-node.
>> >>
>> >> What is
The way the XICS and the XIVE devices are initialized follows the same
pattern. First, try to connect to the KVM device and if not possible
fallback on the emulated device, unless a kernel_irqchip is required.
The spapr_irq_init_device() routine implements this sequence in
generic way using new sPA
On Wed, Mar 20, 2019 at 04:26:32PM +, Paul Durrant wrote:
> The mail thread at [1] clarifies that the Xen blkif protocol requires that
> sector based quantities should be interpreted strictly as multiples of
> 512 bytes. This patch modifies the xen-block code accordingly.
>
> [1] https://lists
XIVE hcalls are all redirected to QEMU as none are on a fast path.
When necessary, QEMU invokes KVM through specific ioctls to perform
host operations. QEMU should have done the necessary checks before
calling KVM and, in case of failure, H_HARDWARE is simply returned.
H_INT_ESB is a special case
Add a check to make sure that the routine initializing the emulated
IRQ device is called once. We don't have much to test on the XICS
side, so we introduce a 'static bool'. Not very elegant but works well
enough.
Signed-off-by: Cédric Le Goater
---
hw/intc/spapr_xive.c | 9 +
hw/intc/xi
On 3/14/19 2:10 PM, Marc-André Lureau wrote:
> In order to make slirp a standalone project, the project must have a
> clear license, and be compatible with the GPL or LGPL.
>
> Since commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec ("Remove the
> advertising clause from the slirp license"), slirp i
On Thu 21 Mar 2019 12:53:57 PM CET, Vladimir Sementsov-Ogievskiy wrote:
>>> Yes, we probably need to rethink this scenario a bit.
>>
>> But yes, even with a counter, the other problem would still remain
>> (that the first job can't remove the filter on completion because the
>> second one has froz
spapr_ics_create() is only called once. Merge it in spapr_irq_init_xics()
and simplify a bit the error handling by using 'error_fatal' .
Signed-off-by: Cédric Le Goater
---
hw/ppc/spapr_irq.c | 44 ++--
1 file changed, 14 insertions(+), 30 deletions(-)
di
The interrupt mode is chosen by the CAS negotiation process and
activated after a reset to take into account the required changes in
the machine. This brings new constraints on how the associated KVM IRQ
device is initialized.
Currently, each model takes care of the initialization of the KVM
devic
While running the GCC test suite against 4.0.0-rc0, Kito found a
regression introduced by the decodetree conversion that caused divuw and
remuw to sign-extend their inputs. The ISA manual says they are
supposed to be zero extended:
DIVW and DIVUW instructions are only valid for RV64, and divi
Am 21.03.2019 um 15:23 hat Alberto Garcia geschrieben:
> On Thu 21 Mar 2019 09:30:26 AM CET, Vladimir Sementsov-Ogievskiy wrote:
> > 20.03.2019 20:25, Alberto Garcia wrote:
> >> On Wed 20 Mar 2019 10:35:27 AM CET, Vladimir Sementsov-Ogievskiy wrote:
> Maybe at least this kind of freezing isn't
Hi Alex,
thanks also for the other patch series that I'm testing right now to speed
up Travis :)
Just a comment below:
On Thu, Mar 21, 2019 at 12:48:57PM +, Alex Bennée wrote:
> This build keeps timing out on Travis and it's unlikely including the
> additional guest front-ends will catch any
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 15:00
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org;
> qemu-devel@nongnu.org; Stefan Hajnoczi
> ; Stefano Stabellini ; Kevin
> Wolf ; Max
> Reitz
> Subje
Thanks, Peter
See my comments below, please
On Thu, 21 Mar 2019 at 14:10, Peter Xu wrote:
>
> On Wed, Mar 20, 2019 at 04:05:58PM +0800, chenxi He wrote:
> > On Wed, 20 Mar 2019 at 13:07, Peter Xu wrote:
> > >
> > > On Tue, Mar 19, 2019 at 11:49:22AM -0400, Catherine Ho wrote:
> > > > Commit 1826
On 03/19/2019 09:47 AM, Alex Bennée wrote:
We define a new class of targets (MAIN_SOFTMMU_TARGETS) to cover the
major architectures. We either just build those or use the new
target-list-exclude mechanism to remove them from the list. This will
hopefully stop some of the longer builds hitting t
On 03/19/2019 09:48 AM, Alex Bennée wrote:
This is essentially a softmmu tweak so don't bother building
linux-user builds as well.
Signed-off-by: Alex Bennée
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Wainer dos Santos Moschetta
diff --git a/.t
On 20/03/2019 20:02, Alberto Garcia wrote:
> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
>>> Oh, I see. Let's use a shorter chain for simplicity:
>>>
>>> A <- B <- C <- D <- E
>>
>> Written from right to left, i.e. E being the base and A the top layer?
>> We usually write things the
On 3/20/19 11:38 PM, Markus Armbruster wrote:
> Yesterday's "dnf upgrade" on my F28 box upgraded gcc to
> gcc-8.2.1-6.fc28.x86_64 from 8.3.1-2.fc28.x86_64. Since then (I think),
> builds fail for me, details appended. Any ideas?
>
> My temporary work-around is configure --disable-tcg.
No ideas.
Verified with gcc testsuite on rv64gc, no new regression introduced, and
get less fails.
Palmer Dabbelt 於 2019年3月21日 週四，22:59寫道：
> While running the GCC test suite against 4.0.0-rc0, Kito found a
> regression introduced by the decodetree conversion that caused divuw and
> remuw to sign-extend the
Stefano Garzarella writes:
> Hi Alex,
> thanks also for the other patch series that I'm testing right now to speed
> up Travis :)
>
> Just a comment below:
>
> On Thu, Mar 21, 2019 at 12:48:57PM +, Alex Bennée wrote:
>> This build keeps timing out on Travis and it's unlikely including the
>
Ouch, thanks for checking that tracing is working. I will send fixes.
Stefan
signature.asc
Description: PGP signature
Signed-off-by: Yuval Shaia
---
hw/net/virtio-net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 7e2c2a6f6a..ffe0872fff 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2281,7 +2281,7 @@ static void virtio_net_cha
On Thu, Mar 21, 2019 at 03:57:43PM +, Alex Bennée wrote:
>
> Stefano Garzarella writes:
>
> > Hi Alex,
> > thanks also for the other patch series that I'm testing right now to speed
> > up Travis :)
> >
> > Just a comment below:
> >
> > On Thu, Mar 21, 2019 at 12:48:57PM +, Alex Bennée w
Hi,
19.03.2019, 14:52, "Dr. David Alan Gilbert" :
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>> wrote:
>> >
>> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> > > I didn't think migration distinguished between "main memo
On 21/03/2019 15.29, Paolo Bonzini wrote:
> When virtio-vga was added, the intention was to only support it for
> those machines where the firmware does not know about virtio-gpu,
> and supported VGA legacy hardware before virtio-{gpu,vga} were
> introduced.
>
> The Kconfig switch however enabled
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files with
> explicit MIT license header.
>
> Signed-off-by: Marc-André Lureau
> ---
> slirp/src/util.h | 1 +
> slirp/src/arp_table.c | 1 +
> slirp/src/bootp.c | 1 +
> slirp/src/dnss
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files with
> explicit 3-clause BSD license header.
>
> Signed-off-by: Marc-André Lureau
> ---
> slirp/src/dhcpv6.h | 1 +
> slirp/src/ip.h | 1 +
> slirp/src/ip_icmp.h| 1 +
> sl
Stefano Garzarella writes:
> On Thu, Mar 21, 2019 at 03:57:43PM +, Alex Bennée wrote:
>>
>> Stefano Garzarella writes:
>>
>> > Hi Alex,
>> > thanks also for the other patch series that I'm testing right now to speed
>> > up Travis :)
>> >
>> > Just a comment below:
>> >
>> > On Thu, Mar 21
On 03/21/19 12:52, Peter Maydell wrote:
> On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek wrote:
>>
>> Repo: https://github.com/lersek/qemu.git
>> Branch: edk2_build_v3
>>
>> Version 2, that is:
>>
>> [Qemu-devel] [PATCH v2 00/12] bundle edk2 platform firmware with QEMU
>>
>> was posted at:
>>
>>
If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.
This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug
These patches fix compilation issues spotted by Markus Armbruster
. See the patches for details.
Stefan Hajnoczi (2):
trace: handle tracefs path truncation
trace: avoid SystemTap dtrace(1) warnings on empty files
trace/ftrace.c| 12 ++--
scripts/tracetool/format/d.py
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's
dtrace(1) tool prints a warning when processing this input file.
This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there
On 21/03/2019 14:53, Vladimir Sementsov-Ogievskiy wrote:
> 21.03.2019 13:53, Kevin Wolf wrote:
>> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
>>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
> Oh, I see. Let's use a shorter chain for simplicity:
>
> A <- B <-
On Thu, 21 Mar 2019 at 16:55, Laszlo Ersek wrote:
> On 03/21/19 12:52, Peter Maydell wrote:
> > Thanks. Could you check that this works in the OpenBSD VM test?
> > It should just be a matter of
> > make -C build vm-build-openbsd
>
> Actually I tried to do that before posting v3, following the
>
On 21/03/2019 13:53, Kevin Wolf wrote:
> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
Oh, I see. Let's use a shorter chain for simplicity:
A <- B <- C <- D <- E
>>>
>>> Written from right to left, i.e. E being t
On Thu, 21 Mar 2019 at 14:41, Paolo Bonzini wrote:
>
> When virtio-vga was added, the intention was to only support it for
> those machines where the firmware does not know about virtio-gpu,
> and supported VGA legacy hardware before virtio-{gpu,vga} were
> introduced.
>
> The Kconfig switch howev
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files with
> reference to BSD license from slirp COPYRIGHT file.
>
> Signed-off-by: Marc-André Lureau
> ---
> slirp/src/debug.h | 1 +
> slirp/src/if.h | 1 +
> slirp/src/main.h | 1 +
>
On 14/03/2019 14.10, Marc-André Lureau wrote:
> Add SPDX license identifier to clarify the license of files without
> explicit license header.
>
> Signed-off-by: Marc-André Lureau
> ---
> slirp/src/bootp.h | 1 +
> slirp/src/ip6.h| 1 +
> slirp/src/ip6_icmp.h | 1 +
> slirp/src/li
On 03/21/19 17:55, Laszlo Ersek wrote:
> On 03/21/19 12:52, Peter Maydell wrote:
>> On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek wrote:
>>>
>>> Repo: https://github.com/lersek/qemu.git
>>> Branch: edk2_build_v3
>>>
>>> Version 2, that is:
>>>
>>> [Qemu-devel] [PATCH v2 00/12] bundle edk2 platfor
On 03/21/2019 09:48 AM, Alex Bennée wrote:
This build keeps timing out on Travis and it's unlikely including the
additional guest front-ends will catch any failures in the fallback
code.
Signed-off-by: Alex Bennée
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Rev
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +void rx_cpu_unpack_psw(CPURXState *env, int all)
> +{
> +if (env->psw_pm == 0) {
> +env->psw_ipl = extract32(env->psw, PSW_IPL, 4);
> +if (all) {
> +env->psw_pm = extract32(env->psw, PSW_PM, 1);
> +}
> +env
On 03/21/19 14:04, Peter Maydell wrote:
> On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek wrote:
>> In brief, the regression is that the aarch64 system emulator now lists
>> the "virtio-vga" device for the "virt" machine type:
>>
>> $ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
>> name "vi
On 3/21/19 7:59 AM, Palmer Dabbelt wrote:
> While running the GCC test suite against 4.0.0-rc0, Kito found a
> regression introduced by the decodetree conversion that caused divuw and
> remuw to sign-extend their inputs. The ISA manual says they are
> supposed to be zero extended:
>
> DIVW an
On 12/03/2019 17.57, Paolo Bonzini wrote:
> This removes the duplicated initialization code.
>
> Signed-off-by: Paolo Bonzini
> ---
> tests/Makefile.include | 3 --
> tests/test-announce-self.c | 82 --
> tests/virtio-net-test.c| 30 ++
>
On 03/21/19 15:21, Philippe Mathieu-Daudé wrote:
> Le jeu. 21 mars 2019 13:39, Laszlo Ersek a écrit :
>
>> On 03/21/19 01:53, Laszlo Ersek wrote:
>>> Hi Paolo,
>>>
>>> (+libvir-list)
>>>
>>> I'd like to report a regression introduced by this patch set:
>>>
>>> On 03/07/19 21:58, Paolo Bonzini wro
On Thu, 21 Mar 2019 at 17:35, Laszlo Ersek wrote:
> It simply keeps the status quo from before the patchset.
>
> The specific emulation targets that virtio-vga should not be enabled for
> (regardless of other targets / machine types) are arm/aarch64. IOW, in
> the longer term, it's not that virtio
On 3/21/19 4:23 AM, Thomas Huth wrote:
> On 20/03/2019 18.32, John Snow wrote:
>>
>>
>> On 3/1/19 7:20 AM, Thomas Huth wrote:
>>> iotest 235 currently only works with KVM - this is bad for systems where
>>> it is not available, e.g. CI pipelines. The test also works when using
>>> "tcg" as accel
This removes the duplicated initialization code.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Paolo Bonzini
---
tests/Makefile.include | 3 --
tests/test-announce-self.c | 73 --
tests/virtio-net-test.c| 30
3 files changed, 30
Richard Henderson writes:
> On 3/20/19 11:38 PM, Markus Armbruster wrote:
>> Yesterday's "dnf upgrade" on my F28 box upgraded gcc to
>> gcc-8.2.1-6.fc28.x86_64 from 8.3.1-2.fc28.x86_64. Since then (I think),
>> builds fail for me, details appended. Any ideas?
>>
>> My temporary work-around is
Stefan Hajnoczi writes:
> If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
> This is a system misconfiguration and the user must resolve it so that
> applications can perform path-based system calls successfully.
>
> This issue does not occur on real-world systems since trac
On 03/21/19 18:58, Peter Maydell wrote:
> On Thu, 21 Mar 2019 at 17:35, Laszlo Ersek wrote:
>> It simply keeps the status quo from before the patchset.
>>
>> The specific emulation targets that virtio-vga should not be enabled for
>> (regardless of other targets / machine types) are arm/aarch64. I
Stefan Hajnoczi writes:
> target/hppa/trace-events only contains disabled events, resulting in a
> trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's
> dtrace(1) tool prints a warning when processing this input file.
>
> This patch avoids the error by emitting an empty file inste
This is the sixth version of the patch series last posted here:
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg03167.html
Changes since v5 include:
- The code to allow booting from a low memory address has been simplified
and better commented.
- Random devices not supported by the li
This patch adds support for libgloss semihosting to Nios II bare-metal
emulation. The specification for the protocol can be found in the
libgloss sources.
Signed-off-by: Sandra Loosemore
Signed-off-by: Julian Brown
---
qemu-options.hx| 8 +-
target/nios2/Makefile.objs | 2 +-
t
On 21/03/2019 17:08, Stefan Hajnoczi wrote:
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's
dtrace(1) tool prints a warning when processing this input file.
This patch avoids the error by emitting an empty
On 3/21/19 3:23 AM, Thomas Huth wrote:
> pipelines in that case. I had to manually select the test cases in the
> .gitlab-ci.yml file due to this. I don't mind too much, but IMHO "make
> check-block" should simply run everywhere, with every QEMU binary, and
> not only if you've compiled it with th
On 21/03/2019 17:08, Stefan Hajnoczi wrote:
If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.
This issue does not occur on real-world systems
This patch adds support for a generic MMU-less Nios II board that can
be used e.g. for bare-metal compiler testing with the linker script
and startup code provided by libgloss. Nios II booting is also
tweaked so that bare-metal binaries start executing in RAM starting at
0x, rather than an
Patchew URL:
https://patchew.org/QEMU/1553193630-28611-1-git-send-email-san...@codesourcery.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v6 0/2] Nios II generic board config and
semihosting
Message-id: 1553
On 3/21/19 11:10 AM, Markus Armbruster wrote:
> I re-ran the failing compile with "-c -o tcg/tcg-op.o" replaced by "-E
> -dD -o tcg/tcg-op.i", and uploaded the resulting tcg-op.i to
>
> https://www.pond.sub.org/~armbru/debug/tcg-op.i
>
> Diffing this against yours might provide clues.
Either
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git tags/x86-next-pull-request
for you to fetch changes up to 21ee4787e533675
KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:
1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
is always supported") makes GET_SUPPORTED_CPUID return
arch_capabilities even if running on SVM. This makes "-cpu
host,migratable=off" incorrectly expose
On 03/21/19 15:29, Paolo Bonzini wrote:
> When virtio-vga was added, the intention was to only support it for
> those machines where the firmware does not know about virtio-gpu,
> and supported VGA legacy hardware before virtio-{gpu,vga} were
> introduced.
>
> The Kconfig switch however enabled vi
From: Daniel P. Berrangé
The docs currently say that the spec-ctrl feature is needed for both
Spectre variants, but it is only used to address Spectre v2. Also
remove the note about retpolines. The guest OS is usually treated
as a blackbox from host mgmt pov, so it won't have knowledge about
use
Now that kvm_arch_get_supported_cpuid() will only return
arch_capabilities if QEMU is able to initialize the MSR properly,
we know that the feature is safely migratable.
Signed-off-by: Eduardo Habkost
Message-Id: <20190125220606.4864-3-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost
---
tar
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +#define FPSW_MASK 0xfc007cff
> +#define FPSW_RM_MASK 0x0003
> +#define FPSW_DN (1 << 8)
It's slightly confusing to have this as a mask,
> +#define FPSW_CAUSE_MASK 0x00fc
> +#define FPSW_CAUSE_SHIFT 2
> +#define FPSW_CAUSE 2
> +#define FPSW_CA
Currently, the Cascadelake-Server, Icelake-Client, and
Icelake-Server are always generating the following warning:
qemu-system-x86_64: warning: \
host doesn't support requested feature: CPUID.07H:ECX [bit 4]
This happens because OSPKE was never returned by
GET_SUPPORTED_CPUID or x86_cpu_get
From: Daniel P. Berrangé
While the stibp CPU feature is not commonly used by guest OS for spectre
mitigation due to its performance impact, it is none the less best
practice to expose it to all guest OS. This allows the guest OS to
decide whether to make use or it.
Signed-off-by: Daniel P. Berra
On 3/20/19 7:16 AM, Yoshinori Sato wrote:
> +static const char *cond[] = {
> +"eq", "ne", "c", "nc", "gtu", "leu", "pz", "n",
> +"ge", "lt", "gt", "le", "o", "no", "ra", "f"
> +};
const char * const cond[]
Or since they are all very short strings,
const char cond[][4]
> +static const ch
Richard Henderson writes:
> On 3/21/19 11:10 AM, Markus Armbruster wrote:
>> I re-ran the failing compile with "-c -o tcg/tcg-op.o" replaced by "-E
>> -dD -o tcg/tcg-op.i", and uploaded the resulting tcg-op.i to
>>
>> https://www.pond.sub.org/~armbru/debug/tcg-op.i
>>
>> Diffing this agains
The callers to bios_linker_find_file() assert that the file entry returned
is not NULL, except for those in bios_linker_loader_add_pointer(). Add two
asserts in that case for completeness and to facilitate static code analysis.
Signed-off-by: Liam Merwick
---
hw/acpi/bios-linker-loader.c | 2 ++
On 3/1/19 4:39 AM, Cornelia Huck wrote:
To be replaced with a real linux-headers update.
Signed-off-by: Cornelia Huck
This looks straightforward.
Reviewed-by: Eric Farman
---
linux-headers/linux/vfio.h | 4
linux-headers/linux/vfio_ccw.h | 12
2 files changed
On 3/20/19 8:38 PM, Grove, Michael wrote:
> Hi All,
>
> Sorry for going straight to the developers but I have a very complex
> problem. I have QNX application/OS that is licensed to the physical media it
> exists on(media ID). When you boot on bare metal directly from the media all
> is go
Le jeu. 21 mars 2019 18:22, Laszlo Ersek a écrit :
> On 03/21/19 17:55, Laszlo Ersek wrote:
> > On 03/21/19 12:52, Peter Maydell wrote:
> >> On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek wrote:
> >>>
> >>> Repo: https://github.com/lersek/qemu.git
> >>> Branch: edk2_build_v3
> >>>
> >>> Version 2,
Le mar. 19 mars 2019 19:40, Markus Armbruster a écrit :
> Markus Armbruster writes:
>
> > Dear board code maintainers,
> >
> > This is a (rather late) follow-up to the last QEMU summit. Minutes[*]:
> >
> > * Deprecating unmaintained features (devices, targets, backends) in QEMU
> >
> >QEMU
Apply double quotes and period punctuation uniformly.
Signed-off-by: Wainer dos Santos Moschetta
---
tests/docker/Makefile.include | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 60314d293a..c0e1bf57a3
On 03/21/19 21:58, Philippe Mathieu-Daudé wrote:
> Le jeu. 21 mars 2019 18:22, Laszlo Ersek a écrit :
>> Unfortunately, I got the exact same setup error:
>>> ERROR: "x86_64-unknown-openbsd6.1-gcc-4.9.4" either does not exist
>>> or does not work
> $ VERBOSE=1 make
> Or DEBUG=1. If default ./con
On 03/21/19 23:32, Laszlo Ersek wrote:
> Cool, so let me try this. I'm going to download the xz.old file
> manually. Rename it to just xz. It will then match the built-in
> checksum, and will be used as a cached copy. Then I will try building my
> series in *that* ("old") VM.
Summary:
(1) The im
On Thu, Mar 21, 2019 at 05:48:27PM +1100, Alexey Kardashevskiy wrote:
> This corrects rather confusing error messages; can be squashed.
>
> Fixes: 0afa2635ef75 ("spapr: Support NVIDIA V100 GPU with NVLink2",
> 2019-03-12)
> Signed-off-by: Alexey Kardashevskiy
Applied and squashed.
> ---
> hw/
From: Nathaniel Graff
Writes to the SiFive PRCI registers are preserved while leaving the
ready bits set for the HFX/HFR oscillators and the lock bit set for the
PLL.
Signed-off-by: Nathaniel Graff
Reviewed-by: Michael Clark
Reviewed-by: Palmer Dabbelt
Signed-off-by: Palmer Dabbelt
---
hw/r
On Thu, Mar 21, 2019 at 02:50:42PM +0100, Igor Mammedov wrote:
>On Thu, 21 Mar 2019 08:21:53 +0800
>Wei Yang wrote:
>
>> arm and i386 has almost the same function acpi_add_rom_blob(), except
>> giving different FWCfgCallback function.
>>
>> This patch moves acpi_add_rom_blob() to utils.c by passi
Signed-off-by: David Gibson
---
target/ppc/int_helper.c | 70 +++--
1 file changed, 39 insertions(+), 31 deletions(-)
diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 162add561e..f6a088ac08 100644
--- a/target/ppc/int_helper.c
+++ b/target/
Signed-off-by: David Gibson
---
target/ppc/gdbstub.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
index fbf3821f4b..ce3625f44e 100644
--- a/target/ppc/gdbstub.c
+++ b/target/ppc/gdbstub.c
@@ -3
Signed-off-by: David Gibson
---
target/ppc/excp_helper.c | 87
1 file changed, 53 insertions(+), 34 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index beafcf1ebd..ec2c177091 100644
--- a/target/ppc/excp_helper.c
+++ b/targ
101 - 200 of 254 matches
Mail list logo
