Extend the vGIC handling code to deal with different IRQ chip devices
instead of hard-coding the GICv2 in.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
tools/kvm/arm/aarch32/arm-cpu.c|2 +-
tools/kvm/arm/aarch64/arm-cpu.c|2 +-
tools/kvm/arm/gic.c
The virtual GICv3 support in the kernel is currently for ARM64 only,
so the ARM uapi headers lack the defines for the GICv3 KVM device
function IDs.
However this will break compilation for ARM with GICv3 support later,
as the GIC code in kvmtool is shared between ARM and ARM64.
Splitting this
The code currently is assuming fixed sized memory regions for the
distributor and CPU interface. GICv3 needs a dynamic allocation of
it's redistributor region, since it's size depends on the number of
vCPUs.
Also add the necessary code to create a GICv3 IRQ chip instance.
Signed-off-by: Andre
On 23/01/2015 15:32, Dan Carpenter wrote:
Smatch complains that there are some paths where we use uninitialized
data in em_sysenter().
arch/x86/kvm/emulate.c:2410 em_sysenter()
error: potentially using uninitialized 'msr_data'.
The right thing to do is to ensure that the
From: Marc Zyngier marc.zyng...@arm.com
On AArch64 system with a GICv2, the GICC range can be aligned
to the last 4k block of a 64k page, ending up straddling two
64k pages. In order not to conflict with the distributor mapping,
allocate two 64k pages to the CPU interface.
Signed-off-by: Marc
From: Marc Zyngier marc.zyng...@arm.com
As of 3.14, KVM/arm supports the creation/configuration of the GIC through
a more generic device API, which is now the preferred way to do so.
Plumb the new API in, and allow the old code to be used as a fallback.
[Andre: Rename some functions on the way
Add the command line parameter --gicv3 to request GICv3 emulation
in the kernel. Connect that to the already existing GICv3 code.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
tools/kvm/arm/aarch64/arm-cpu.c|5 -
Hi,
this series updates kvmtool to support some new KVM kernel features
related to the virtual GIC.
The first half of the series is mostly from Marc and has been
lingering around for some while, the second part is a slightly revised
and updated version of the virtual GICv3 support series.
We now
We are using the explicit VGIC_CTRL_INIT ioctl, which was introduced
with 3.19-rc1, so at the moment we need to pull this patch from
upstream Linux. This patch can be reverted as soon as a newer Linux
tree is merged into kvmtool.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
This pulls the necessary defines for the GICv3 constants from the
Linux tree into kvmtool for now. Should be obsolete as soon as
the vGICv3 patches are upstream and kvmtool is rebased on top of
it.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arch/arm64/include/uapi/asm/kvm.h |7
From: Marc Zyngier marc.zyng...@arm.com
The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7b (kvm tools: irq: make
irq__alloc_line generic) made the interrupt counter private,
add a new accessor returning the number of interrupt lines we've
Since Linux 3.19-rc1 there is a new API to explicitly initialise
the in-kernel GIC emulation by a userland KVM device call.
Use that to tell the kernel we are finished with the GIC
initialisation, since the automatic GIC init will only be provided
as a legacy functionality in the future.
From: Marc Zyngier marc.zyng...@arm.com
In order to reduce the memory usage of large guests (as well
as improve performance), tell KVM about the number of interrupts
we require.
To avoid synchronization with the various device creation,
use a late_init callback to compute the GIC configuration.
Dear libvirt, KVM, and QEMU contributors,
The Google Summer of Code season begins soon and it's time to collect
our thoughts for mentoring students this summer working full-time on
libvirt, KVM, and QEMU.
What is GSoC?
Google Summer of Code 2015 (GSoC) funds students to
work on open source
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls
On Fri, Jan 23, 2015 at 11:30:16AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it
On Fri, Jan 23, 2015 at 11:51:09AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses some of the cleanups recommended and adds
tracing option for when we do actually preempt a hypercall.
I kept the
On Friday 23 January 2015 12:58:20, Paolo Bonzini wrote:
On 23/01/2015 12:18, Stefan Fritsch wrote:
Wasn't there some issue that Windows guests would then ask for a
driver? AIUI, pvpanic has been disabled by default for this
reason.
Also, it would be nice if simplistic bootloaders without
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
+ */
+void xen_end_upcall(struct pt_regs *regs)
+{
+ if (xen_is_preemptible_hypercall(regs)) {
+ int cpuid = smp_processor_id();
+ if (_cond_resched())
+
On Mon, Jan 12, 2015 at 6:21 PM, Eric Auger eric.au...@linaro.org wrote:
On 12/05/2014 01:06 PM, Nikolay Nikolaev wrote:
On Sat, Nov 29, 2014 at 1:28 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Nov 24, 2014 at 11:26:51PM +0200, Nikolay Nikolaev wrote:
On IO memory
On Fri, Jan 23, 2015 at 01:49:41PM +0100, Paolo Bonzini wrote:
On 23/01/2015 13:01, Paolo Bonzini wrote:
On 23/01/2015 12:35, Mark Rutland wrote:
https://lkml.org/lkml/2015/1/22/7
https://lkml.org/lkml/2015/1/22/8
I'd hoped we'd be able to fix that before this went further
On Fri, Jan 23, 2015 at 12:49:41PM +, Paolo Bonzini wrote:
On 23/01/2015 13:01, Paolo Bonzini wrote:
On 23/01/2015 12:35, Mark Rutland wrote:
https://lkml.org/lkml/2015/1/22/7
https://lkml.org/lkml/2015/1/22/8
I'd hoped we'd be able to fix that before this went further
On Mon, Jan 12, 2015 at 11:41 PM, Eric Auger eric.au...@linaro.org wrote:
On 12/07/2014 10:37 AM, Nikolay Nikolaev wrote:
In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
a single MMIO handling path - that is through the kvm_io_bus_ API.
Register a kvm_io_device in
On Mon, Jan 12, 2015 at 7:09 PM, Eric Auger eric.au...@linaro.org wrote:
Hi Nikolay,
On 12/07/2014 10:37 AM, Nikolay Nikolaev wrote:
On IO memory abort, try to handle the MMIO access thorugh the KVM
registered read/write callbacks. This is done by invoking the relevant
kvm_io_bus_* API.
Hi Christoffer,
On Fri, Jan 23, 2015 at 10:02:32AM +, Christoffer Dall wrote:
From: Wei Huang w...@redhat.com
arm64 uses its own copy of exit handler (arm64/kvm/handle_exit.c).
Currently this file doesn't hook up with any trace points. As a result
users might not see certain events
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses some of the cleanups recommended and adds
tracing option for when we do actually preempt a hypercall.
I kept the NOKPROBE_SYMBOL() for now but did remove the 'notrace'
stuff.
This goes
On 23/01/2015 12:18, Stefan Fritsch wrote:
Wasn't there some issue that Windows guests would then ask for a
driver? AIUI, pvpanic has been disabled by default for this reason.
Also, it would be nice if simplistic bootloaders without ACPI support
would also be able to use the feature.
On 23/01/2015 12:35, Mark Rutland wrote:
https://lkml.org/lkml/2015/1/22/7
https://lkml.org/lkml/2015/1/22/8
I'd hoped we'd be able to fix that before this went further upstream.
The easiest way I could see to do that was to merge my esr branch (which
is stable and Catalin has pulled)
On Thu, Jan 22, 2015 at 07:18:25PM +, Marc Zyngier wrote:
On 22/01/15 19:13, Mario Smarduch wrote:
On 01/22/2015 01:34 AM, Paul Bolle wrote:
Mario,
Your commit c64735554c0a (KVM: arm: Add initial dirty page locking
support) is included in today's linux-next (ie, next-20150122). I
On Thu, Jan 22, 2015 at 04:32:37PM +0100, Paolo Bonzini wrote:
On 22/01/2015 15:49, Paul Bolle wrote:
Ah, there are two Kconfig symbols added by mistake.
+config HAVE_KVM_ARCH_DIRTY_LOG_PROTECT
+ bool
+
+config KVM_GENERIC_DIRTYLOG_READ_PROTECT
+ bool
This one is
On 23/01/2015 10:40, Stefan Fritsch wrote:
Hi,
there are situations where a guest needs to wait, but has interrupts
disabled. Usually this is done by polling in a tight loop, which is a
waste of CPU cycles on a virtualized system. Therefore I propose to
add a hypercall to KVM that
From: Mario Smarduch m.smard...@samsung.com
This patch enables ARMv8 ditry page logging support. Plugs ARMv8 into generic
layer through Kconfig symbol, and drops earlier ARM64 constraints to enable
logging at architecture layer.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
From: Eric Auger eric.au...@linaro.org
Since the advent of VGIC dynamic initialization, this latter is
initialized quite late on the first vcpu run or on-demand, when
injecting an IRQ or when the guest sets its registers.
This initialization could be initiated explicitly much earlier
by the
From: Andre Przywara andre.przyw...@arm.com
Currently the trace printk talks about wfi only, though the trace
point triggers both on wfi and wfe traps.
Add a parameter to differentiate between the two.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Wei Huang w...@redhat.com
From: Mario Smarduch m.smard...@samsung.com
This patch adds support for arm64 hyp interface to flush all TLBs associated
with VMID.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Mario Smarduch m.smard...@samsung.com
---
arch/arm64/kvm/hyp.S | 22 ++
From: Wei Huang w...@redhat.com
arm64 uses its own copy of exit handler (arm64/kvm/handle_exit.c).
Currently this file doesn't hook up with any trace points. As a result
users might not see certain events (e.g. HVC WFI) while using ftrace
with arm64 KVM. This patch fixes this issue by adding a
From: Eric Auger eric.au...@linaro.org
To be more explicit on vgic initialization failure, -ENODEV is
returned by vgic_init when no online vcpus can be found at init.
Signed-off-by: Eric Auger eric.au...@linaro.org
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
Hi Paolo,
Please pull from kvmarm/next for changes adding GICv3 emulation, dirty
page logging, added trace symbols, and adding an explicit VGIC init
device control IOCTL.
The following changes since commit bab5bb398273bb37547a185f7b344b37c700d0b9:
kvm: x86: Remove kvm_make_request from
From: Andre Przywara andre.przyw...@arm.com
The virtual MPIDR registers (containing topology information) for the
guest are currently mapped linearily to the vcpu_id. Improve this
mapping for arm64 by using three levels to not artificially limit the
number of vCPUs.
To help this, change and
From: Mario Smarduch m.smard...@samsung.com
Add support to track dirty pages between user space KVM_GET_DIRTY_LOG ioctl
calls. We call kvm_get_dirty_log_protect() function to do most of the work.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Reviewed-by: Marc Zyngier
From: Mario Smarduch m.smard...@samsung.com
Allow architectures to override the generic kvm_flush_remote_tlbs()
function via HAVE_KVM_ARCH_TLB_FLUSH_ALL. ARMv7 will need this to
provide its own TLB flush interface.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Reviewed-by: Marc
From: Mario Smarduch m.smard...@samsung.com
kvm_get_dirty_log() provides generic handling of dirty bitmap, currently reused
by several architectures. Building on that we intrdoduce
kvm_get_dirty_log_protect() adding write protection to mark these pages dirty
for future write access, before next
From: Mario Smarduch m.smard...@samsung.com
Add support for initial write protection of VM memslots. This patch
series assumes that huge PUDs will not be used in 2nd stage tables, which is
always valid on ARMv7
Acked-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Mario Smarduch
The dirty patch logging series introduced both
HAVE_KVM_ARCH_DIRTY_LOG_PROTECT and KVM_GENERIC_DIRTYLOG_READ_PROTECT
config symbols, but only KVM_GENERIC_DIRTYLOG_READ_PROTECT is used.
Just remove the unused one.
(The config symbol was renamed during the development of the patch
series and the
A comment in the dirty page logging patch series mentioned incorrectly
spelled config symbols, just fix them up to match the real thing.
Reported-by: Paul Bolle pebo...@tiscali.nl
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
arch/arm/kvm/mmu.c | 4 ++--
1 file changed, 2
From: Andre Przywara andre.przyw...@arm.com
To check whether the vGIC was already initialized, we currently check
the GICH base address for not being NULL. Since with GICv3 we may
get along without this address, lets use the irqchip_in_kernel()
function to detect an already initialized vGIC.
From: Andre Przywara andre.przyw...@arm.com
Currently we only need to deal with one MMIO region for the GIC
emulation (the GICv2 distributor), but we soon need to extend this.
Refactor the existing code to allow easier addition of different
ranges without code duplication.
Signed-off-by: Andre
From: Paolo Bonzini pbonz...@redhat.com
We now have a generic function that does most of the work of
kvm_vm_ioctl_get_dirty_log, now use it.
Acked-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Mario Smarduch m.smard...@samsung.com
---
arch/x86/include/asm/kvm_host.h | 3 --
From: Andre Przywara andre.przyw...@arm.com
Currently we unconditionally register the GICv2 emulation device
during the host's KVM initialization. Since with GICv3 support we
may end up with only v2 or only v3 or both supported, we move the
registration into the GIC probing function, where we
From: Andre Przywara andre.przyw...@arm.com
The MMIO accessors for GICD_I[CS]ENABLER, GICD_I[CS]PENDR and
GICD_ICFGR behave very similar for GICv2 and GICv3, although the way
the affected VCPU is determined differs.
Since we need them to access the registers from three different
places in the
From: Andre Przywara andre.przyw...@arm.com
Although the GIC architecture requires us to map the MMIO regions
only at page aligned addresses, we currently do not enforce this from
the kernel side.
Restrict any vGICv2 regions to be 4K aligned and any GICv3 regions
to be 64K aligned. Document this
Hi,
there are situations where a guest needs to wait, but has interrupts
disabled. Usually this is done by polling in a tight loop, which is a
waste of CPU cycles on a virtualized system. Therefore I propose to
add a hypercall to KVM that allows the guest to yield the CPU for a
specified
On Friday 23 January 2015 10:53:00, Paolo Bonzini wrote:
On 23/01/2015 10:40, Stefan Fritsch wrote:
Hi,
there are situations where a guest needs to wait, but has
interrupts disabled. Usually this is done by polling in a tight
loop, which is a waste of CPU cycles on a virtualized
From: Andre Przywara andre.przyw...@arm.com
ICC_SRE_EL1 is a system register allowing msr/mrs accesses to the
GIC CPU interface for EL1 (guests). Currently we force it to 0, but
for proper GICv3 support we have to allow guests to use it (depending
on their selected virtual GIC model).
So add
From: Andre Przywara andre.przyw...@arm.com
While the generation of a (virtual) inter-processor interrupt (SGI)
on a GICv2 works by writing to a MMIO register, GICv3 uses the system
register ICC_SGI1R_EL1 to trigger them.
Add a trap handler function that calls the new SGI register handler
in the
From: Andre Przywara andre.przyw...@arm.com
For a GICv2 there is always only one (v)CPU involved: the one that
does the access. On a GICv3 the access to a CPU redistributor is
memory-mapped, but not banked, so the (v)CPU affected is determined by
looking at the MMIO address region being accessed.
From: Andre Przywara andre.przyw...@arm.com
vgic.c is currently a mixture of generic vGIC emulation code and
functions specific to emulating a GICv2. To ease the addition of
GICv3, split off strictly v2 specific parts into a new file
vgic-v2-emul.c.
Signed-off-by: Andre Przywara
From: Andre Przywara andre.przyw...@arm.com
Some GICv3 registers can and will be accessed as 64 bit registers.
Currently the register handling code can only deal with 32 bit
accesses, so we do two consecutive calls to cover this.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by:
From: Andre Przywara andre.przyw...@arm.com
Currently the maximum number of vCPUs supported is a global value
limited by the used GIC model. GICv3 will lift this limit, but we
still need to observe it for guests using GICv2.
So the maximum number of vCPUs is per-VM value, depending on the
GIC
From: Andre Przywara andre.przyw...@arm.com
With all the necessary GICv3 emulation code in place, we can now
connect the code to the GICv3 backend in the kernel.
The LR register handling is different depending on the emulated GIC
model, so provide different implementations for each.
Also allow
From: Mario Smarduch m.smard...@samsung.com
This patch adds ARMv7 architecture TLB Flush function.
Acked-by: Marc Zyngier marc.zyng...@arm.com
Acked-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Mario Smarduch m.smard...@samsung.com
---
arch/arm/include/asm/kvm_asm.h | 1 +
From: Andre Przywara andre.przyw...@arm.com
Currently we only have one virtual GIC model supported, so all guests
use the same emulation code. With the addition of another model we
end up with different guests using potentially different vGIC models,
so we have to split up some functions to be
From: Andre Przywara andre.przyw...@arm.com
With the introduction of a second emulated GIC model we need to let
userspace specify the GIC model to use for each VM. Pass the
userspace provided value down into the vGIC code and store it there
to differentiate later.
Signed-off-by: Andre Przywara
From: Andre Przywara andre.przyw...@arm.com
With everything separated and prepared, we implement a model of a
GICv3 distributor and redistributors by using the existing framework
to provide handler functions for each register group.
Currently we limit the emulation to a model enforcing a single
From: Mario Smarduch m.smard...@samsung.com
This patch adds support for 2nd stage page fault handling while dirty page
logging. On huge page faults, huge pages are dissolved to normal pages, and
rebuilding of 2nd stage huge pages is blocked. In case migration is
canceled this restriction is
From: Andre Przywara andre.przyw...@arm.com
vgic.c is currently a mixture of generic vGIC emulation code and
functions specific to emulating a GICv2. To ease the addition of
GICv3 later, we create new header file vgic.h, which holds constants
and prototypes of commonly used functions.
Rename some
From: Andre Przywara andre.przyw...@arm.com
With all of the GICv3 code in place now we allow userland to ask the
kernel for using a virtual GICv3 in the guest.
Also we provide the necessary support for guests setting the memory
addresses for the virtual distributor and redistributors.
This
From: Andre Przywara andre.przyw...@arm.com
The gic_send_sgi() function used hardcoded bit shift values to
generate the ICC_SGI1R_EL1 register value.
Replace this with symbolic names to allow reusing them later.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Christoffer Dall
From: Mario Smarduch m.smard...@samsung.com
This patch adds arm64 helpers to write protect pmds/ptes and retrieve
permissions while logging dirty pages. Also adds prototype to write protect
a memory slot and adds a pmd define to check for read-only pmds.
Reviewed-by: Christoffer Dall
From: Andre Przywara andre.przyw...@arm.com
vgic_set_attr() and vgic_get_attr() contain both code specific for
the emulated GIC as well as code for the userland facing, generic
part of the GIC.
Split the guest GIC facing code of from the generic part to allow
easier splitting later.
On Wed, Jan 21, 2015 at 11:39:44AM +0100, Paolo Bonzini wrote:
On 21/01/2015 11:32, Zhang Haoyu wrote:
Hi,
Does drive_mirror support incremental backup a running vm?
Or other mechanism does?
incremental backup a running vm requirements:
First time backup, all of the allocated
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such
Smatch complains that there are some paths where we use uninitialized
data in em_sysenter().
arch/x86/kvm/emulate.c:2410 em_sysenter()
error: potentially using uninitialized 'msr_data'.
A couple examples of paths which don't set pdata are found in
get_msr_hyperv() and
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v3 addresses Stefano's feedback from the v2 series, namely
moving PCI stuff to x86 as its all x86 specific and also just
2015-01-23 17:32+0300, Dan Carpenter:
Smatch complains that there are some paths where we use uninitialized
data in em_sysenter().
arch/x86/kvm/emulate.c:2410 em_sysenter()
error: potentially using uninitialized 'msr_data'.
I have two hypotheses why smatch thinks so
1)
From: David Hildenbrand d...@linux.vnet.ibm.com
We have to delete the allocated interrupt info if __inject_vm() fails.
Otherwise user space can keep flooding kvm with floating interrupts and
provoke more and more memory leaks.
Reported-by: Dominik Dingel din...@linux.vnet.ibm.com
Reviewed-by:
On 23/01/2015 13:01, Paolo Bonzini wrote:
On 23/01/2015 12:35, Mark Rutland wrote:
https://lkml.org/lkml/2015/1/22/7
https://lkml.org/lkml/2015/1/22/8
I'd hoped we'd be able to fix that before this went further upstream.
The easiest way I could see to do that was to merge my esr
Linus,
The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:
Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
From: Jens Freimann jf...@linux.vnet.ibm.com
When we convert interrupt data from struct kvm_s390_interrupt to
struct kvm_s390_irq we need to check the data in the input parameter
not the output parameter.
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Acked-by: Christian Borntraeger
From: Jens Freimann jf...@linux.vnet.ibm.com
Setting inti-type again is unnecessary here, so let's
remove this.
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
Paolo,
here is the pull request for the RFC from last week.
Patch 1 got a new patch description (Paolo)
Patch 14 changed UL to ULL (Heiko)
Patch 22-24 are new fixes.
There is one interesting problem that popped up when we acidentially
enabled ntp. All KVM architectures use hrtimers for wakeups.
From: Dominik Dingel din...@linux.vnet.ibm.com
The return value of kvm_arch_vcpu_postcreate is not checked in its
caller. This is okay, because only x86 provides vcpu_postcreate right
now and it could only fail if vcpu_load failed. But that is not
possible during KVM_CREATE_VCPU
From: David Hildenbrand d...@linux.vnet.ibm.com
We need a way to clear the async pfault queue from user space (e.g.
for resets and SIGP SET ARCHITECTURE).
This patch simply clears the queue as soon as user space sets the
invalid pfault token. The definition of the invalid token is moved
to uapi.
84 matches
Mail list logo
