On Thu, 6 Dec 2018 at 15:23, Marc-André Lureau
wrote:
>
> Hi
>
> On Thu, Dec 6, 2018 at 10:38 AM wrote:
> >
> > From: Xie Yongji
> >
> > Now we attempt to connect asynchronously for "reconnect socket"
> > during open(). But vhost-user device prefer a connected socket
> > during initialization.
On Thu, 6 Dec 2018 at 15:23, Marc-André Lureau
wrote:
>
> Hi
>
> On Thu, Dec 6, 2018 at 10:36 AM wrote:
> >
> > From: Xie Yongji
> >
> > This patchset is aimed at supporting qemu to reconnect
> > vhost-user-blk backend after vhost-user-blk backend crash or
> > restart.
> >
> > The patch 1 tries
On 2018/12/5 下午10:47, Jintack Lim wrote:
On Tue, Dec 4, 2018 at 8:30 PM Jason Wang wrote:
On 2018/12/5 上午2:37, Jintack Lim wrote:
Hi,
I'm wondering how the current implementation works when logging dirty
pages during migration from vhost-net (in kernel) when used vIOMMU.
I understand how
On 2018/12/5 下午9:32, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2018 at 11:02:11AM +0800, Jason Wang wrote:
On 2018/12/5 上午9:59, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2018 at 09:30:19AM +0800, Jason Wang wrote:
On 2018/12/5 上午2:37, Jintack Lim wrote:
Hi,
I'm wondering how the current
Hi
On Thu, Dec 6, 2018 at 10:38 AM wrote:
>
> From: Xie Yongji
>
> Now we attempt to connect asynchronously for "reconnect socket"
> during open(). But vhost-user device prefer a connected socket
> during initialization. That means we may still need to support
> sync connection during open()
On Thu, 6 Dec 2018 at 15:19, Marc-André Lureau
wrote:
>
> Hi
> On Thu, Dec 6, 2018 at 10:40 AM wrote:
> >
> > From: Xie Yongji
> >
> > This introduces a new message VHOST_USER_SET_VRING_INFLIGHT
> > to support offering shared memory to backend to record
> > its inflight I/O.
> >
> > With this
Hi
On Thu, Dec 6, 2018 at 10:36 AM wrote:
>
> From: Xie Yongji
>
> This patchset is aimed at supporting qemu to reconnect
> vhost-user-blk backend after vhost-user-blk backend crash or
> restart.
>
> The patch 1 tries to implenment the sync connection for
> "reconnect socket".
>
> The patch 2
Hi
On Thu, Dec 6, 2018 at 10:40 AM wrote:
>
> From: Xie Yongji
>
> This introduces a new message VHOST_USER_SET_VRING_INFLIGHT
> to support offering shared memory to backend to record
> its inflight I/O.
>
> With this new message, the backend is able to restart without
> missing I/O which would
On Thu, Dec 6, 2018 at 10:40 AM wrote:
>
> From: Xie Yongji
>
> Introduce vu_queue_map_desc() which should be
> independent with vu_queue_pop();
>
> Signed-off-by: Xie Yongji
> Signed-off-by: Zhang Yu
Reviewed-by: Marc-André Lureau
> ---
> contrib/libvhost-user/libvhost-user.c | 86
Markus Armbruster writes:
> Eric Blake writes:
>
>> RFC8259 obsoletes RFC7159. Fix a couple of URLs to point to the
>> newer version.
>>
>> Signed-off-by: Eric Blake
>
> Reviewed-by: Markus Armbruster
Queued, thanks!
Daniel Henrique Barboza writes:
> changes in v11:
> - fixed typos, changed version to 4.0 in patches 1 and 3
> - changed text in patch 2 to be less alarming
> - patch 3: changed error handling
> - previous version link:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01774.html
Daniel Henrique Barboza writes:
> The qmp/hmp command 'system_wakeup' is simply a direct call to
> 'qemu_system_wakeup_request' from vl.c. This function verifies if
> runstate is SUSPENDED and if the wake up reason is valid before
> proceeding. However, no error or warning is thrown if any of
Daniel Henrique Barboza writes:
> This patch updates the descriptions of 'guest-suspend-ram' and
> 'guest-suspend-hybrid' to mention that both commands relies now
> on the proper support for wake up from suspend, retrieved by the
> 'wakeup-suspend-support' attribute of the
Daniel Henrique Barboza writes:
> When issuing the qmp/hmp 'system_wakeup' command, what happens in a
> nutshell is:
>
> - qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason
> and notify the event
> - in the main_loop, all vcpus are paused, a system reset is issued, all
>
From: Xie Yongji
This patch tells qemu that we now support inflight I/O recording
so that qemu could offer shared memory to it.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/vhost-user-blk/vhost-user-blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Xie Yongji
This introduces a new message VHOST_USER_SET_VRING_INFLIGHT
to support offering shared memory to backend to record
its inflight I/O.
With this new message, the backend is able to restart without
missing I/O which would cause I/O hung for block device.
Signed-off-by: Xie Yongji
From: Xie Yongji
Introduce vu_queue_map_desc() which should be
independent with vu_queue_pop();
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/libvhost-user/libvhost-user.c | 86 +++
1 file changed, 49 insertions(+), 37 deletions(-)
diff --git
From: Xie Yongji
This patch adds support for VHOST_USER_SET_VRING_INFLIGHT
message. Now we maintain a "bitmap" of all descriptors in
the shared memory for each queue. Then set it in vu_queue_pop()
and clear it in vu_queue_push();
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
From: Xie Yongji
Since the new message VHOST_USER_SET_VRING_INFLIGHT,
the backend is able to restart safely. This patch
allow qemu to reconnect the backend after connection
closed.
Signed-off-by: Xie Yongji
Signed-off-by: Ni Xun
Signed-off-by: Zhang Yu
---
hw/block/vhost-user-blk.c
From: Xie Yongji
Now we attempt to connect asynchronously for "reconnect socket"
during open(). But vhost-user device prefer a connected socket
during initialization. That means we may still need to support
sync connection during open() for the "reconnect socket".
Signed-off-by: Xie Yongji
From: Xie Yongji
This patchset is aimed at supporting qemu to reconnect
vhost-user-blk backend after vhost-user-blk backend crash or
restart.
The patch 1 tries to implenment the sync connection for
"reconnect socket".
The patch 2 introduces a new message VHOST_USER_SET_VRING_INFLIGHT
to
On 11/30/2018 11:45 AM, Fei Li wrote:
On 11/29/2018 10:46 PM, Philippe Mathieu-Daudé wrote:
Hi Fei,
On 29/11/18 11:03, Fei Li wrote:
In our current code, when multifd is used during migration, if there
is an error before the destination receives all new channels, the
source keeps
On 12/6/18 5:09 AM, David Gibson wrote:
> On Thu, Dec 06, 2018 at 12:22:20AM +0100, Cédric Le Goater wrote:
>> The Event Notification Descriptor (END) XIVE structure also contains
>> two Event State Buffers providing further coalescing of interrupts,
>> one for the notification event (ESn) and one
Hi
On Thu, Dec 6, 2018 at 10:08 AM Markus Armbruster wrote:
>
> One more question...
>
> Marc-André Lureau writes:
>
> > Not all backends are able to switch gcontext. Those backends cannot
> > drive a OOB monitor (the monitor would then be blocking on main
> > thread).
> >
> > For example,
On Thu, Dec 6, 2018 at 4:38 AM Marc-André Lureau <
marcandre.lur...@redhat.com> wrote:
> COLO uses a worker context (iothread) to drive the chardev. All
> backends are not able to switch the context, let's report an error in
> this case.
>
> Signed-off-by: Marc-André Lureau
>
Reviewed-by: Zhang
On 12/6/18 4:41 AM, David Gibson wrote:
> On Thu, Dec 06, 2018 at 12:22:18AM +0100, Cédric Le Goater wrote:
>> The XiveRouter models the second sub-engine of the XIVE architecture :
>> the Interrupt Virtualization Routing Engine (IVRE).
>>
>> The IVRE handles event notifications of the IVSE and
One more question...
Marc-André Lureau writes:
> Not all backends are able to switch gcontext. Those backends cannot
> drive a OOB monitor (the monitor would then be blocking on main
> thread).
>
> For example, ringbuf, spice, or more esoteric input chardevs like
> braille or MUX.
These
Hello,
> Your patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> Checking PATCH 25/37: spapr/xive: add state synchronization with KVM...
> Checking PATCH 26/37: spapr/xive: introduce a VM state
On 12/6/18 4:25 AM, David Gibson wrote:
> On Thu, Dec 06, 2018 at 12:22:17AM +0100, Cédric Le Goater wrote:
>> The XiveNotifier offers a simple interface, between the XiveSource
>> object and the main interrupt controller of the machine. It will
>> forward event notifications to the XIVE Interrupt
On 12/5/2018 2:37 PM, Liam Merwick wrote:
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, QEMU should be able to boot directly into the
uncompressed Linux kernel binary with
On 12/06/2018 04:37 AM, Marc-André Lureau wrote:
COLO uses a worker context (iothread) to drive the chardev. All
backends are not able to switch the context, let's report an error in
this case.
Signed-off-by: Marc-André Lureau
Reviewed-by: Li Zhijian
---
net/colo-compare.c | 6
I'd like an Acked-by or Reviewed-by from Zhang Chen or Li Zhijian.
Marc-André Lureau writes:
> COLO uses a worker context (iothread) to drive the chardev. All
> backends are not able to switch the context, let's report an error in
> this case.
>
> Signed-off-by: Marc-André Lureau
> ---
>
Marc-André Lureau writes:
> Not all backends are able to switch gcontext. Those backends cannot
> drive a OOB monitor (the monitor would then be blocking on main
> thread).
>
> For example, ringbuf, spice, or more esoteric input chardevs like
> braille or MUX.
>
> We currently forbid MUX because
Marc-André Lureau writes:
> QEMU_CHAR_FEATURE_GCONTEXT declares the character device can switch
> GMainContext.
>
> Assert we don't switch context when the character device doesn't
> provide this feature. Character device users must not violate this
> restriction. In particular, user
On Thu, Dec 06, 2018 at 12:22:21AM +0100, Cédric Le Goater wrote:
> Each POWER9 processor chip has a XIVE presenter that can generate four
> different exceptions to its threads:
>
> - hypervisor exception,
> - O/S exception
> - Event-Based Branch (EBB)
> - msgsnd (doorbell).
>
> Each
On 2018-12-05 18:30, Philippe Mathieu-Daudé wrote:
> On 12/3/18 3:05 PM, Thomas Huth wrote:
>> So far we only had implicit requirements for the minimum compiler version,
>> e.g. we require at least GCC 4.1 for the support of atomics. However,
>> such old compiler versions are not tested anymore by
On Thu, Dec 06, 2018 at 12:22:17AM +0100, Cédric Le Goater wrote:
> The XiveNotifier offers a simple interface, between the XiveSource
> object and the main interrupt controller of the machine. It will
> forward event notifications to the XIVE Interrupt Virtualization
> Routing Engine (IVRE).
>
>
On Thu, Dec 06, 2018 at 12:22:20AM +0100, Cédric Le Goater wrote:
> The Event Notification Descriptor (END) XIVE structure also contains
> two Event State Buffers providing further coalescing of interrupts,
> one for the notification event (ESn) and one for the escalation events
> (ESe). A MMIO
On Thu, Dec 06, 2018 at 12:22:19AM +0100, Cédric Le Goater wrote:
> To complete the event routing, the IVRE sub-engine uses a second table
> containing Event Notification Descriptor (END) structures.
>
> An END specifies on which Event Queue (EQ) the event notification
> data, defined in the
On Thu, Dec 06, 2018 at 12:22:18AM +0100, Cédric Le Goater wrote:
> The XiveRouter models the second sub-engine of the XIVE architecture :
> the Interrupt Virtualization Routing Engine (IVRE).
>
> The IVRE handles event notifications of the IVSE and performs the
> interrupt routing process. For
Some address/memory APIs have different type between
'hwaddr/target_ulong addr' and 'int len'. It is very unsafe, espcially
some APIs will be passed a non-int len by caller which might cause
overflow quietly.
Below is an potential overflow case:
dma_memory_read(uint32_t len)
->
Don't expect read(2) can always read as many as it's told.
Signed-off-by: Li Zhijian
Reviewed-by: Richard Henderson
---
V4: add reviewed-by tag
---
hw/core/loader.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/core/loader.c b/hw/core/loader.c
index
Long long ago, linux kernel has supported up to 4G initrd, but it's header
still hard code to allow loading initrd below 2G only.
cutting from arch/x86/head.S:
# (Header version 0x0203 or later) the highest safe address for the contents
# of an initrd. The current kernel allows up to 4 GB, but
it's from v4.20-rc5.
CC: Michael S. Tsirkin
Signed-off-by: Li Zhijian
---
V4: use scirpt to import bootparam.h (Michael S. Tsirkin)
V3: new patch
Signed-off-by: Li Zhijian
---
hw/i386/pc.c | 8 +--
include/standard-headers/asm-x86/bootparam.h | 34
a new field xloadflags was added to recent x86 linux, and BIT 1:
XLF_CAN_BE_LOADED_ABOVE_4G is used to tell bootload that where initrd can be
loaded safely.
Current QEMU/BIOS always loads initrd below below_4g_mem_size which is always
less than 4G, so here limiting initrd_max to 4G - 1 simply is
On 12/05/2018 11:33 PM, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2018 at 06:28:11PM +0800, Li Zhijian wrote:
Hi Michael
I cooked a draft with cp_portable to import bootparam.h, could you have a look.
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index
On 12/05/2018 01:40 AM, Philippe Mathieu-Daudé wrote:
Hi Li,
On 3/12/18 15:48, Li Zhijian wrote:
Some address/memory APIs have different type between
'hwaddr/target_ulong addr' and 'int len'. It is very unsafety, espcially
I'm not native English speaker, but I think this should be spell:
>On Wed, 5 Dec 2018 at 00:28, wrote:
>>
>> >I'm afraid I don't understand. If it's a PCI device then
>> >it does not need to be listed in the device tree or the
>> >ACPI tables at all, because it is probeable by the guest.
>> >This also significantly simplifies the changes needed in QEMU.
>> >
>>
On Wed, 5 Dec 2018 at 18:36, Leif Lindholm wrote:
>
> On Wed, Dec 05, 2018 at 05:50:23PM +0800, Hongbo Zhang wrote:
> > > > +static
> > > > +void sbsa_ref_machine_done(Notifier *notifier, void *data)
> > > > +{
> > > > +VirtMachineState *vms = container_of(notifier, VirtMachineState,
> > > >
Patchew URL: https://patchew.org/QEMU/20181205232251.10446-1-...@kaod.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20181205232251.10446-1-...@kaod.org
Subject: [Qemu-devel] [PATCH v6 00/37] ppc: support for the XIVE
On 05.12.2018 22:58, Ed Maste wrote:
> On Wed, 5 Dec 2018 at 15:59, Kamil Rytarowski wrote:
>>
>> There are already FreeBSD, OpenBSD and NetBSD test scripts in the qemu
>> project.
>
> I see scripts under tests/vm/ for FreeBSD, NetBSD, and OpenBSD, but
> they're for testing BSD guests on QEMU,
If I remote iothreads and writeback caching, it seems more reliable, but
I can still get it to hang.
This time the source server shows the VM as running, backtrace looks
like:
(gdb) bt full
#0 0x7f27eab0028c in __lll_lock_wait () at /lib64/libpthread.so.0
#1 0x7f27eaaf9d35 in
Public bug reported:
Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9
Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9
When this VM is running on source server:
/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S
-object
Patchew URL:
https://patchew.org/QEMU/1544049446-6359-1-git-send-email-liam.merw...@oracle.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST
Patchew URL:
https://patchew.org/QEMU/20181205195704.17605-1-ehabk...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20181205195704.17605-1-ehabk...@redhat.com
Subject: [libvirt] [PATCH for-4.0 v4 0/2] virtio: Provide
The KVM IRQ device activation will depend 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
---
hw/intc/spapr_xive_kvm.c | 28
hw/intc/xics_kvm.c |
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
This routine gathers all the KVM initialization of the XICS KVM
presenter. It will be useful when the initialization of the KVM XICS
device is moved to a global routine.
Signed-off-by: Cédric Le Goater
---
hw/intc/xics_kvm.c | 29 -
1 file changed, 20 insertions(+),
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
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
Currently, the interrupt presenter of the vCPU is set at realize
time. Setting it at reset will become useful when the new machine
supporting both interrupt modes is introduced. In this machine, the
interrupt mode is chosen at CAS time and activated after a reset.
Signed-off-by: Cédric Le Goater
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
This introduces a set of helpers to activate the KVM XIVE device when
KVM is in use.
They handle the initialization of the TIMA and the source ESB memory
regions which have a different type under KVM. These are 'ram device'
memory mappings, similarly to VFIO, exposed to the guest and the
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 masks the sources (PQ=01) to stop
the flow of events and
This pseries machine makes use of a new sPAPR IRQ backend supporting
both interrupt modes : XIVE and XICS, the default being XICS.
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. These impact the
Depending on the interrupt mode chosen, enable or disable the XIVE
MMIOs.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr_xive.h | 1 +
hw/intc/spapr_xive.c| 9 +
hw/ppc/spapr_irq.c | 8
3 files changed, 18 insertions(+)
diff --git
For the time being, the XIVE reset handler updates the OS CAM line of
the vCPU as it is done under a real hypervisor when a vCPU is
scheduled to run on a HW thread.
This method will become even more useful when the machine supporting
both interrupt modes, XIVE and XICS, is introduced. In this
When the thread interrupt management state is retrieved from the KVM
VCPU, word2 is saved under the QEMU XIVE thread context to print out
the OS CAM line under the QEMU monitor.
This breaks the migration on a TCG guest (or on KVM with
kernel_irqchip=off) because the matching algorithm of the
When the VM is stopped, the VM state handler stabilizes the XIVE IC
and marks the EQ pages dirty. These are then transfered 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
The XIVE sPAPR IRQ backend will use it to define the number of ENDs of
the IC controller.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr.h | 1 +
hw/ppc/spapr.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/hw/ppc/spapr.h
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
The different XIVE virtualization structures (sources and event queues)
are configured with a set of Hypervisor calls :
- H_INT_GET_SOURCE_INFO
used to obtain the address of the MMIO page of the Event State
Buffer (ESB) entry associated with the source.
- H_INT_SET_SOURCE_CONFIG
The XIVE IRQ backend uses the same layout as the new XICS backend but
covers the full range of the IRQ number space. The IRQ numbers for the
CPU IPIs are allocated at the bottom of this space, below 4K, to
preserve compatibility with XICS which does not use that range.
This should be enough given
Introduce a new sPAPR IRQ handler to handle resend after migration
when the machine is using a KVM XICS interrupt controller model.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr_irq.h | 2 ++
hw/ppc/spapr.c | 13
These changes provide the initial 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-4.20
The IVPE scans the O/S CAM line of the XIVE thread interrupt contexts
to find a matching Notification Virtual Target (NVT) among the NVTs
dispatched on the HW processor threads.
On a real system, the thread interrupt contexts are updated by the
hypervisor when a Virtual Processor is scheduled to
sPAPRXive models the XIVE interrupt controller of the sPAPR machine.
It inherits from the XiveRouter and provisions storage for the routing
tables :
- Event Assignment Structure (EAS)
- Event Notification Descriptor (END)
The sPAPRXive model incorporates an internal XiveSource for the IPIs
Each interrupt mode has its own specific interrupt presenter object,
that we store under the CPU object, one for XICS and one for XIVE.
The XIVE model hardwires the NVT identifier in the thread context
model to emulate the push/pull of hypervisor when a vCPU is dispatched
on a HW thread.
The
The interrupt mode is statically defined to XIVE only for this machine.
The guest OS is required to have support for the XIVE exploitation
mode of the POWER9 interrupt controller.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr.h | 6 ++
include/hw/ppc/spapr_irq.h | 1 +
To complete the event routing, the IVRE sub-engine uses a second table
containing Event Notification Descriptor (END) structures.
An END specifies on which Event Queue (EQ) the event notification
data, defined in the associated EAS, should be posted when an
exception occurs. It also defines which
The last sub-engine of the XIVE architecture is the Interrupt
Virtualization Presentation Engine (IVPE). On HW, the IVRE and the
IVPE share elements, the Power Bus interface (CQ), the routing table
descriptors, and they can be combined in the same HW logic. We do the
same in QEMU and combine both
Each POWER9 processor chip has a XIVE presenter that can generate four
different exceptions to its threads:
- hypervisor exception,
- O/S exception
- Event-Based Branch (EBB)
- msgsnd (doorbell).
Each exception has a state independent from the others called a Thread
Interrupt Management
The XIVE interface for the guest is described in the device tree under
the "interrupt-controller" node. A couple of new properties are
specific to XIVE :
- "reg"
contains the base address and size of the thread interrupt
managnement areas (TIMA), for the User level and for the Guest OS
Add a 'nr_irqs' parameter to the 'init' method to remove the use of
the machine class. This will be useful when we introduce the machine
supporting the two sPAPR IRQ backends : XICS and XIVE.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr_irq.h | 2 +-
hw/ppc/spapr_irq.c | 7
The XiveNotifier offers a simple interface, between the XiveSource
object and the main interrupt controller of the machine. It will
forward event notifications to the XIVE Interrupt Virtualization
Routing Engine (IVRE).
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/xive.h | 23
Initialize the MSI bitmap from it as this will be necessary for the
sPAPR IRQ backend for XIVE.
Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
---
include/hw/ppc/spapr_irq.h | 1 +
hw/ppc/spapr.c | 2 +-
hw/ppc/spapr_irq.c | 16 +++-
3 files
The first sub-engine of the overall XIVE architecture is the Interrupt
Virtualization Source Engine (IVSE). An IVSE can be integrated into
another logic, like in a PCI PHB or in the main interrupt controller
to manage IPIs.
Each IVSE instance is associated with an Event State Buffer (ESB) that
We will need to use xics_max_server_number() to create the sPAPRXive
object modeling the interrupt controller of the machine which is
created before the CPUs.
Signed-off-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/ppc/spapr.c | 10 +-
1 file changed, 5 insertions(+), 5
The XiveRouter models the second sub-engine of the XIVE architecture :
the Interrupt Virtualization Routing Engine (IVRE).
The IVRE handles event notifications of the IVSE and performs the
interrupt routing process. For this purpose, it uses a set of tables
stored in system memory, the first of
After the event data was enqueued in the O/S Event Queue, the IVPE
raises the bit corresponding to the priority of the pending interrupt
in the register IBP (Interrupt Pending Buffer) to indicate there is an
event pending in one of the 8 priority queues. The Pending Interrupt
Priority Register
The 'sent' status of the LSI interrupt source is modeled with the 'P'
bit of the ESB and the assertion status of the source is maintained
with an extra bit under the main XiveSource object. The type of the
source is stored in the same array for practical reasons.
Signed-off-by: Cédric Le Goater
The Event Notification Descriptor (END) XIVE structure also contains
two Event State Buffers providing further coalescing of interrupts,
one for the notification event (ESn) and one for the escalation events
(ESe). A MMIO page is assigned for each to control the EOI through
loads only. Stores are
Hello,
Here is the version 6 of the QEMU models adding support for the XIVE
interrupt controller to the sPAPR machine, under TCG and KVM. Support
for the PowerNV POWER9 machine will be proposed in a PowerNV patchset
sometime next year now.
The most important changes for sPAPR are the removal of
On Wed, Dec 05, 2018 at 08:59:06AM +0100, David Hildenbrand wrote:
> On 05.12.18 06:06, David Gibson wrote:
> > Currently, virtio-balloon uses madvise() with MADV_DONTNEED to actually
> > discard RAM pages inserted into the balloon. This is basically a Linux
> > only interface (MADV_DONTNEED
On Wed, Dec 05, 2018 at 06:58:24PM -0200, Eduardo Habkost wrote:
> Instead of setting use_hotplug_event_source at instance_init
> time, set default_machine_opts on spapr_machine_2_7_class_options()
> to implement equivalent behavior.
>
> This will let us eliminate the need for separate
On Wed, Dec 05, 2018 at 06:58:25PM -0200, Eduardo Habkost wrote:
> Instead of setting suppress_vmdesc at instance_init time, set
> default_machine_opts on spapr_machine_2_2_class_options() to
> implement equivalent behavior.
>
> This will let us eliminate the need for separate instance_init
>
On Wed, Dec 05, 2018 at 06:58:26PM -0200, Eduardo Habkost wrote:
> Now that all instance_options functions for spapr are empty,
> delete them.
>
> Signed-off-by: Eduardo Habkost
Acked-by: David Gibson
Do you want me to stage the ppc patches in my ppc-for-4.0 tree, or
would you prefer to keep
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, QEMU should be able to boot directly into the
uncompressed Linux kernel binary with minimal firmware involvement.
There already
These changes (along with corresponding qboot and Linux kernel changes)
enable a guest to be booted using the x86/HVM direct boot ABI.
This commit adds a load_elfboot() routine to pass the size and
location of the kernel entry point to qboot (which will fill in
the start_info struct information
From: Liam Merwick
The x86/HVM direct boot ABI permits Qemu to be able to boot directly
into the uncompressed Linux kernel binary without the need to run firmware.
https://xenbits.xen.org/docs/unstable/misc/pvh.html
This commit adds the header file that defines the start_info struct
1 - 100 of 386 matches
Mail list logo
