Public bug reported:
Boot failed after installing Checkpoint Pointsec FDE
Hi,
I installed Windows 10 64-bit guest on CentOS 7. Everything works great as
expected.
However after installing CheckPoint AlertSec full disk encryption, the guest
failed to boot.
The following error is displayed in q
Correct the output of the "info mem" and "info tlb" monitor commands to
correctly show canonical addresses.
In 48-bit addressing mode, the upper 16 bits of linear addresses are
equal to bit 47. In 57-bit addressing mode (LA57), the upper 7 bits of
linear addresses are equal to bit 56.
Signed-off-
Philippe Mathieu-Daudé writes:
> Hi Alex,
>
> On 06/15/2018 04:46 PM, Alex Bennée wrote:
>> The fixed path and ports get in the way of running our tests and
>> builds in parallel. Instead of using TESTPATH we use mkdtemp() and
>> instead of a fixed port we allow the kernel to assign one and que
On 15/06/18 11:37, Thomas Huth wrote:
Hi Mark, hi Artyom,
while using valgrind to fix some issues with the rom_ptr() function
today, I noticed that there is one more problem in sun4u_load_kernel():
The kernel_top variable can be used uninitialized in some cases:
If load_elf() fails and the ke
Public bug reported:
Hi,
QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0
run the program in qemu-2.12.0:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
static uintptr_t syz_open_dev(uintptr_t a0, uint
** Information type changed from Private Security to Public Security
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1777315
Title:
Denial of service
Status in QEMU:
New
Bug description:
Hi,
Hi,
QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0
run the program in qemu-2.12.0:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: cover.1529196703.git.k...@juliacomputing.com
Subject: [Qemu-devel] [PATCH v3 00/13] 9p: Add support for Darwin
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(gi
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180615222855.44421-1-...@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/2] kvm: limited x86 CPU power management
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(
Fix the helper_fpscr_clrbit() function so it correctly
sets the FEX and VX bits.
Signed-off-by: John Arbuckle
---
target/ppc/fpu_helper.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index
On 17 June 2018 at 06:36, Richard Henderson
wrote:
> On 06/15/2018 12:55 AM, Peter Maydell wrote:
>>> +uint32_t armv6m_insn[] = {0xf3808000 /* msr */, 0xf3b08040 /* dsb */,
>>> + 0xf3b08050 /* dmb */, 0xf3b08060 /* isb */,
>>> + 0xf3e08
This patch fixes the assumption that io_buffer_size is always a perfect
multiple of the sector size. The assumption is the cause of the firing
of 'assert(n * 512 == s->sg.size);'.
Signed-off-by: Amol Surati
---
hw/ide/core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
di
This is an attempt at fixing the bug #1777315, through code review
alone (i.e. test and debugging are pending.)
The function bmdma_prepare_buf shows that s->io_buffer_size can be
controlled through the PRDs, and it is possible for it to not be a
perfect multiple of the sector size (the function id
On 17.06.2018 19:33, Peter Maydell wrote:
On 17 June 2018 at 06:36, Richard Henderson
wrote:
On 06/15/2018 12:55 AM, Peter Maydell wrote:
+uint32_t armv6m_insn[] = {0xf3808000 /* msr */, 0xf3b08040 /* dsb */,
+ 0xf3b08050 /* dmb */, 0xf3b08060 /* isb */,
+
On Fri, Jun 15, 2018 at 06:58:00PM +0200, Greg Kurz wrote:
> Commit 3d85885a1b1f3 tried to fix error handling, but it actually
> went into the wrong direction by dropping the local Error *.
>
> In the default KVM case, the rationale is to try the in-kernel XICS first,
> and if not possible, to fal
On Sun, Jun 17, 2018 at 11:53:09AM -0400, John Arbuckle wrote:
> Fix the helper_fpscr_clrbit() function so it correctly
> sets the FEX and VX bits.
This needs a lot more information in the commit message:
* What exactly was wrong with the previous setting of the FEX and VX
bits?
* Where
On Fri, Jun 15, 2018 at 04:04:44PM +0200, David Hildenbrand wrote:
> We don't allow to modify it after realization. So we can simply turn
> it into a static property.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: David Gibson
> ---
> hw/mem/nvdimm.c | 32 +++-
>
On Fri, Jun 15, 2018 at 04:04:45PM +0200, David Hildenbrand wrote:
> This way we can easily check if the region has already been inititalized
> without having to rely on the size of an uninitialized region being 0.
>
> Signed-off-by: David Hildenbrand
I'm not terribly convinced that this is a wo
On Fri, Jun 15, 2018 at 04:04:48PM +0200, David Hildenbrand wrote:
> Let's try to reduce error handling a bit. In the plug/unplug case, the
> device was realized and therefore we can assume that getting access to
> the memory region will not fail.
>
> For get_vmstate_memory_region() this is alread
On Fri, Jun 15, 2018 at 04:04:38PM +0200, David Hildenbrand wrote:
> Let's rename it to make it look more consistent.
>
> Reviewed-by: Igor Mammedov
> Signed-off-by: David Hildenbrand
Reviewed-by: David Gibson
ppc parts
Acked-by: David Gibson
> ---
> hw/i386/pc.c | 4 ++--
> h
On Fri, Jun 15, 2018 at 04:04:39PM +0200, David Hildenbrand wrote:
> Not used outside of pc-dimm.c and there shouldn't be other users. If
> other devices (e.g. memory devices) ever have to also use slots, then we
> will have to factor this out.
>
> Reviewed-by: Igor Mammedov
> Signed-off-by: Davi
On Thu, Jun 14, 2018 at 09:51:33AM +0200, BALATON Zoltan wrote:
> On Thu, 14 Jun 2018, David Gibson wrote:
> > On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> > > Signed-off-by: BALATON Zoltan
> >
> > Patch looks good, but it needs a commit message. What is the
> > directcntl r
On Fri, Jun 15, 2018 at 04:04:37PM +0200, David Hildenbrand wrote:
> Use a similar naming scheme as spapr. This way, we can go ahead and
> rename e.g. pc_dimm_memory_plug to pc_dimm_plug, which avoids
> confusion.
>
> Reviewed-by: Igor Mammedov
> Signed-off-by: David Hildenbrand
Reviewed-by: Da
On Fri, Jun 15, 2018 at 04:04:43PM +0200, David Hildenbrand wrote:
> Importantly, get_vmstate_memory_region() should also fail with a proper
> error if called before the device is realized. For a PCDIMM, both functions
> are to return the same thing, so share the implementation.
>
> All current us
On Fri, Jun 15, 2018 at 11:35:37AM +0200, BALATON Zoltan wrote:
> On Thu, 14 Jun 2018, David Gibson wrote:
> > On Thu, Jun 14, 2018 at 10:03:41AM +0200, BALATON Zoltan wrote:
> > > On Thu, 14 Jun 2018, David Gibson wrote:
> > > > On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> > >
On Thu, Jun 14, 2018 at 10:06:33AM +0200, BALATON Zoltan wrote:
> On Thu, 14 Jun 2018, David Gibson wrote:
> > On Thu, Jun 14, 2018 at 02:17:00AM +0200, BALATON Zoltan wrote:
> > > Signed-off-by: BALATON Zoltan
> >
> > Again needs a commit message expanding on what this is and why it's
> > useful
> On Jun 17, 2018, at 8:34 PM, David Gibson wrote:
>
> On Sun, Jun 17, 2018 at 11:53:09AM -0400, John Arbuckle wrote:
>> Fix the helper_fpscr_clrbit() function so it correctly
>> sets the FEX and VX bits.
>
> This needs a lot more information in the commit message:
>
> * What exactly was wro
On Wed, Jun 13, 2018 at 04:03:18PM +0200, BALATON Zoltan wrote:
> On Wed, 13 Jun 2018, David Gibson wrote:
> > On Wed, Jun 13, 2018 at 10:54:22AM +0200, BALATON Zoltan wrote:
> > > On Wed, 13 Jun 2018, David Gibson wrote:
> > > > On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> > >
On Wed, May 09, 2018 at 12:23:49PM +0100, Peter Maydell wrote:
> On 9 May 2018 at 06:32, David Gibson wrote:
> > On Sun, May 06, 2018 at 04:04:02PM +0100, Peter Maydell wrote:
> >> On 6 May 2018 at 14:39, David Gibson wrote:
> >> > Although, that said, I'll re-iterate that I think qemu's fdt
> >>
On Fri, Apr 20, 2018 at 05:39:42PM +0200, Greg Kurz wrote:
> On Fri, 20 Apr 2018 11:15:01 +0200
> Greg Kurz wrote:
>
> > On Fri, 20 Apr 2018 16:34:37 +1000
> > David Gibson wrote:
> >
> > > On Thu, Apr 19, 2018 at 03:48:23PM +0200, Greg Kurz wrote:
> > > > On Tue, 17 Apr 2018 17:17:13 +1000
>
From: Greg Kurz
If the negotiated compat mode can't be set, but raw mode is supported,
we decide to ignore the error. An so, we should free it to prevent a
memory leak.
Signed-off-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: David Gibson
---
hw/ppc/spapr_hcall.c | 1 +
1
From: Greg Kurz
Commit 9d6f106552fa moved the last line in this block to somewhere else,
but it forgot to remove the now useless #if/#endif.
Signed-off-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: David Gibson
---
target/ppc/cpu.h | 2 --
1 file changed, 2 deletions(-)
d
From: Suraj Jitindar Singh
In default_caps_with_cpu() we set spapr_cap_cfpc to broken for POWER8
processors and before.
Since we no longer require private l1d cache on POWER8 for this cap to
be set to workaround change this to default to broken for POWER7
processors and before.
Signed-off-by: S
From: Mark Cave-Ayland
MacOS 9 has a bug in its PMU driver whereby after configuring the ADB bus
devices it sends another write to reg 3 on both devices resetting them
both back to the same address.
Add a new disable_direct_reg3_writes property to ADBDevice to disable these
direct writes which c
From: Suraj Jitindar Singh
For cap_ppc_safe_cache to be set to workaround, we require both a l1d
cache flush instruction and private l1d cache.
On POWER8 don't require private l1d cache. This means a guest on a
POWER8 machine can make use of the cache flush workarounds.
Signed-off-by: Suraj Jit
The following changes since commit 2ef2f16781af9dee6ba6517755e9073ba5799fa2:
Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20180615a'
into staging (2018-06-15 18:13:35 +0100)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-3.0-2018
From: Mark Cave-Ayland
The programmer switch is wired up via an external GPIO pin and can be used
to aid debugging Mac guests.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
hw/misc/macio/gpio.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/misc/macio/
From: Mark Cave-Ayland
This option allows the VIA configuration to be controlled between 3
different possible setups: cuda, pmu-adb and pmu with USB rather than ADB
keyboard/mouse.
For the moment we don't do anything with the configuration except to pass
it to the macio device (the via-cuda pare
From: Mark Cave-Ayland
According to the 6522 datasheet the shift register (SR) interrupt flag is
cleared upon write with no mention of any other interrupt flags.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
hw/misc/mos6522.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
From: Mark Cave-Ayland
According to the Apple ADB documentation, register 3 is a 2-byte register
with the device address in the first byte, and the handler ID in the second
byte.
This is currently the opposite away to which QEMU returns them so switch the
order around.
Signed-off-by: Mark Cave-
From: Mark Cave-Ayland
This is in preparation for adding configuration controlled via machine
options.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
hw/ppc/mac.h | 11 +++
hw/ppc/mac_newworld.c | 7 +++
2 files changed, 18 insertions(+)
diff --git a/hw
From: Mark Cave-Ayland
PMU-enabled New World Macs expose their GPIOs via a separate memory region
within the macio device.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
default-configs/ppc-softmmu.mak | 1 +
hw/misc/macio/Makefile.objs | 1 +
hw/misc/macio/gpio.c
From: Greg Kurz
Commit 94ad93bd97684 (QEMU 2.12) switched to instantiate CPUs separately
but it missed to adapt the error path accordingly. If something fails in
the CPU creation loop, then the CPU object that was just created is leaked.
The error paths in this function are a bit obfuscated, and
In pnv_core_realize() we call two functions with an Error * parameter in
succession, which will go badly if they both cause errors. In fact, a
failure in either of them indicates a qemu internal error, so we can just
use &error_abort in both cases.
Signed-off-by: David Gibson
Reviewed-by: Cédric
From: Greg Kurz
Because this is the preferred practice in QEMU.
Signed-off-by: Greg Kurz
Signed-off-by: David Gibson
---
hw/ppc/spapr_cpu_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 7fdb3b6667..ad404d1
From: Mark Cave-Ayland
In the case where we have an interrupt generated externally from inputs to
bits 1 and 2 of port A and/or port B, it is necessary to expose
mos6522_update_irq() so it can be called by the interrupt source.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
h
spapr_cpu_init() and spapr_cpu_destroy() are only called from the spapr
cpu core realize/unrealize paths, and really can only be called from there.
Those are all short functions, so fold the pairs together for simplicity.
While we're there rename some functions and change some parameter types
for
From: BALATON Zoltan
When writing registers that have read only bits we have to avoid
changing these bits as they may have non zero values. Make sure we use
the correct masks to mask out read only and reserved bits when
changing registers.
Also remove extra spaces from dram_control and arbitrati
From: Greg Kurz
The spapr_realize_vcpu() function doesn't rollback in case of error.
This isn't a problem with coldplugged CPUs because the machine won't
start and QEMU will exit. Hotplug is a different story though: the
CPU thread is started under object_property_set_bool() and it assumes
it can
From: Cédric Le Goater
This extracts from the PvChip realize routine the part creating the
cores. On Power9, we will need to create the cores after the Xive
interrupt controller is created.
Signed-off-by: Cédric Le Goater
Signed-off-by: David Gibson
---
hw/ppc/pnv.c | 32 +
From: Mark Cave-Ayland
The datasheet indicates that the interrupt is generated by ANDing the
interrupt flags register (IFR) with the interrupt enable register (IER)
but currently there is an extra filter for the SR and timer interrupts.
Remove this extra filter to allow interrupts to be generate
pnv_cpu_init() is only called from the the pnv cpu core realize path, and
really only can be called from there. So fold it into its caller, which
we also rename for brevity.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/ppc/pnv_core.c | 56 +++
Currently, we allocate space for all the cpu objects within a single core
in one big block. This was copied from an older version of the spapr code
and requires some ugly pointer manipulation to extract the individual
objects.
This design was due to a misunderstanding of qemu lifetime conventions
From: Greg Kurz
Commit 3d85885a1b1f3 tried to fix error handling, but it actually
went into the wrong direction by dropping the local Error *.
In the default KVM case, the rationale is to try the in-kernel XICS first,
and if not possible, to fallback to userland XICS. Passing errp everywhere
mak
From: Cédric Le Goater
On CentOS 7.5, gcc-4.8.5-28.el7_5.1.ppc64le fails to build QEMU due to :
hw/intc/xics_kvm.c: In function ‘ics_set_kvm_state’:
hw/intc/xics_kvm.c:281:13: error: ‘ret’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
return ret;
CPUPPCState currently contains a number of fields containing the state of
the VPA. The VPA is a PAPR specific concept covering several guest/host
shared memory areas used to communicate some information with the
hypervisor.
As a PAPR concept this is really machine specific information, although i
From: Greg Kurz
This moves some code out from spapr_cpu_core_realize() for clarity. No
functional change.
Signed-off-by: Greg Kurz
Signed-off-by: David Gibson
---
hw/ppc/spapr_cpu_core.c | 73 +
1 file changed, 45 insertions(+), 28 deletions(-)
diff --
Currently we don't have any unrealize path for pnv cpu cores. We get away
with this because we don't yet support cpu hotplug for pnv.
However, we're going to want it eventually, and in the meantime, it makes
it non-obvious why there are a bunch of allocations on the realize() path
that don't have
From: Mark Cave-Ayland
The PMU device supercedes the CUDA device found on older New World Macs and
is supported by a larger number of guest OSs from OS 9 to OS X 10.5.
Signed-off-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
default-configs/ppc-softmmu.mak | 1 +
hw/misc/macio/Makefi
On Fri, Jun 15, 2018 at 01:53:01PM +0200, Cédric Le Goater wrote:
> Today, when a device requests for IRQ number in a sPAPR machine, the
> spapr_irq_alloc() routine first scans the ICSState status array to
> find an empty slot and then performs the assignement of the selected
> numbers. Split this
On Fri, Jun 15, 2018 at 05:25:33PM +0200, Cédric Le Goater wrote:
> On Power9, the thread interrupt presenter has a different type and is
> linked to the chip owning the cores.
>
> Signed-off-by: Cédric Le Goater
Applied to ppc-for-3.0, thanks.
> ---
> include/hw/ppc/pnv.h | 1 +
> hw/ppc/pnv
On Fri, Jun 15, 2018 at 01:53:02PM +0200, Cédric Le Goater wrote:
> spapr_irq_alloc_block and spapr_irq_alloc() are now deprecated.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
> ---
> include/hw/ppc/spapr.h | 4 ---
> hw/ppc/spapr.c | 80
> +
On Fri, Jun 15, 2018 at 05:25:34PM +0200, Cédric Le Goater wrote:
> This moves the details of the ISA bus creation under the LPC model but
> more important, the new PnvChip operation will let us choose the chip
> class to use when we introduce the different chip classes for Power9
> and Power8. It
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1386197
Title:
keyboard su
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1222034
Title:
QEMU + SPIC
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1228285
Title:
e1000 nic T
Matthias Maier writes:
> This is a different approach to fix the locale dependent encode/decode
> problem in common.py utilizing the binary read/write mode [1,2], and (if
> a python 3 interpreter is used) with explicit decode/encode arguments
> [3].
Why can't we simply pass encoding='utf-8' to o
Sorry, but I have a hard to to imagine what you exactly mean here. Do
you mean a possibility for one application in the guest and one in the
host to share a piece of memory? Or do you mean that the operating
systems in the host and guest should somehow share the memory (why?)? Or
do you just look f
Thomas Huth <1777...@bugs.launchpad.net> writes:
> I'm sorry, but Solaris is currently unsupported and might get removed in
> a future release, see:
>
> https://wiki.qemu.org/ChangeLog/2.12#Warning:_unsupported_host_systems
Quote configure:
if test "$supported_os" = "no"; then
echo
echo
Are you going to provide a patch for this to the mailing list? (since
you've assigned the bug to yourself)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1777315
Title:
Denial of service
Status in
Eduardo Habkost writes:
> On Fri, Jun 15, 2018 at 03:16:09PM +0100, Daniel P. Berrangé wrote:
>> With the recent set of CPU hardware vulnerabilities on x86, it is
>> increasingly difficult to understand which CPU configurations are
>> good to use and what flaws they might be vulnerable to.
>>
>>
Oh no, this is a misunderstanding.
More Details:
use this script
https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh
create
wheezy.img
than run:
qemu-system-x86_64 -m 2048 -smp 1 -net nic -net
user,host=10.0.2.10,hostfwd=tcp::59199-:22 -display none -serial stdio
KVM HV has a restriction that for HPT mode guests, guest pages must be hpa
contiguous as well as gpa contiguous. We have to account for that in
various places. We determine whether we're subject to this restriction
from the SMMU information exposed by KVM.
Planned cleanups to the way we handle t
ppc_check_compat() is used in a number of places to check if a cpu object
supports a certain compatiblity mode, subject to various constraints.
It takes a PowerPCCPU *, however it really only depends on the cpu's class.
We have upcoming cases where it would be useful to make compatibility
checks b
Previously, the effective values of the various spapr capability flags
were only determined at machine reset time. That was a lazy way of making
sure it was after cpu initialization so it could use the cpu object to
inform the defaults.
But we've now improved the compat checking code so that we d
spapr capabilities have an apply hook to actually activate (or deactivate)
the feature in the system at reset time. However, a number of capabilities
affect the setup of cpus, and need to be applied to each of them -
including hotplugged cpus for extra complication. To make this simpler,
add an o
Currently the "pseries" machine type will (usually) advertise
different pagesizes to the guest when running under KVM and TCG, which
is not how things are supposed to work.
This comes from poor handling of hardware limitations which mean that
under KVM HV the guest is unable to use pagesizes large
The way the POWER Hash Page Table (HPT) MMU is virtualized by KVM HV means
that every page that the guest puts in the pagetables must be truly
physically contiguous, not just GPA-contiguous. In effect this means that
an HPT guest can't use any pagesizes greater than the host page size used
to back
The paravirtualized PAPR platform sometimes needs to restrict the guest to
using only some of the page sizes actually supported by the host's MMU.
At the moment this is handled in KVM specific code, but for consistency we
want to apply the same limitations to all accelerators.
This makes a start o
KVM HV has some limitations (deriving from the hardware) that mean not all
host-cpu supported pagesizes may be usable in the guest. At present this
means that KVM guests and TCG guests may see different available page sizes
even if they notionally have the same vcpu model. This is confusing and
a
Currently during KVM initialization on POWER, kvm_fixup_page_sizes()
rewrites a bunch of information in the cpu state to reflect the
capabilities of the host MMU and KVM. This overwrites the information
that's already there reflecting how the TCG implementation of the MMU will
operate.
This means
Hi,
> (Which I think is true in the specific case of "info usbhost",
> because it's really just a wrapper around libusb. I'm 100% sure
> QEMU doesn't need to provide a QMP interface for libusb.)
Agree.
I think we can settle that specific case by deprecating and removing
"info usbhost". lsusb
The way we used to handle KVM allowable guest pagesizes for PAPR guests
required some convoluted checking of memory attached to the guest.
The allowable pagesizes advertised to the guest cpus depended on the memory
which was attached at boot, but then we needed to ensure that any memory
later hotp
On Fri, 15 Jun 2018 19:21:19 +0200
Cédric Le Goater wrote:
> On 06/15/2018 03:14 PM, Greg Kurz wrote:
> > On Fri, 15 Jun 2018 13:53:01 +0200
> > Cédric Le Goater wrote:
> >
> >> Today, when a device requests for IRQ number in a sPAPR machine, the
> >> spapr_irq_alloc() routine first scans the
84 matches
Mail list logo
