On Fri, 2022-12-30 at 12:01 -0500, Stefan Berger wrote:
> On 12/30/22 10:24, James Bottomley wrote:
[...]
> > @@ -2906,9 +2893,7 @@ void qemu_init(int argc, char **argv)
> > break;
> > #ifdef CONFIG_TPM
> > case QEMU_OPTION_tpmdev:
> > - if (tpm_conf
On 12/30/22 17:06, H. Peter Anvin wrote
TThe 62 MB limit mentioned in boot.rst is unrelated, and only applies to
very, very old kernels that used INT 15h, AH=88h to probe memory.
I am 88% sure this was fixed long before setup_data was created, as it
was created originally to carry e820 inf
On 12/30/22 14:10, Jason A. Donenfeld wrote:
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note th
Am 29. Dezember 2022 10:58:48 UTC schrieb Thomas Huth :
>The only reason for this code being target dependent is the apic-related
>code in rtc_policy_slew_deliver_irq(). Since these apic functions are rather
>simple, we can easily move them into a new, separate file (apic_irqcount.c)
>which will
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note that I sent v2/v3, to fix the original problem in a
The setup_data links are appended to the compressed kernel image. Since
the kernel image is typically loaded at 0x10, setup_data lives at
`0x10 + compressed_size`, which does not get relocated during the
kernel's boot process.
The kernel typically decompresses the image starting at address
On Fri, Dec 30, 2022 at 07:38:19PM +0100, Jason A. Donenfeld wrote:
> The microvm machine has a gross hack where it fiddles with fw_cfg data
> after the fact. So this hack is updated to account for this appending,
> by reserving some bytes.
This is a little derpy. I'll send a v3 in a second to cle
On December 30, 2022 11:54:11 AM PST, Borislav Petkov wrote:
>On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
>> Look closer at the boot process. The compressed image is initially at
>> 0x10, but it gets relocated to a safer area at the end of
>> startup_64:
>
>That is the
On Fri, Dec 30, 2022 at 08:24:19AM -0800, Richard Henderson wrote:
> Mirroring the upstream gdb xml files, the two stack boundary
> registers are separated out.
Reviewed-by: Edgar E. Iglesias
>
> Signed-off-by: Richard Henderson
> ---
>
> I did this thinking I would be fixing:
>
> TEST
Increase the allocated buffer size to fit larger packets.
Given that jumboframes can commonly be up to 9000 bytes the closest suitable
value seems to be 16 KiB.
Tested by running qemu towards a Linux L2TPv3 endpoint and pushing
jumboframe traffic through the interfaces.
Signed-off-by: Christian S
On Fri, Dec 30, 2022 at 09:13:29AM +0100, Philippe Mathieu-Daudé wrote:
> On 29/12/22 21:52, Peter Delevoryas wrote:
> > On Thu, Dec 29, 2022 at 04:23:22PM +0100, Philippe Mathieu-Daudé wrote:
> > > Since I don't have access to the datasheet, the relevant
> > > values were found in:
> > > https://g
On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote:
> Look closer at the boot process. The compressed image is initially at
> 0x10, but it gets relocated to a safer area at the end of
> startup_64:
That is the address we're executing here from, rip here looks like 0x100xxx.
>
On December 30, 2022 7:59:30 AM PST, "Jason A. Donenfeld"
wrote:
>Hi,
>
>On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
>> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
>> wrote:
>> >Hi,
>> >
>> >Read this message in a fixed width text editor with a lot of columns.
The setup_data links are appended to the compressed kernel image. Since
the kernel image is typically loaded at 0x10, setup_data lives at
`0x10 + compressed_size`, which does not get relocated during the
kernel's boot process.
The kernel typically decompresses the image starting at address
On Fri, Dec 30, 2022 at 01:31:35PM +0100, Philippe Mathieu-Daudé wrote:
> On 30/12/22 12:34, Philippe Mathieu-Daudé wrote:
> > When booting the Zephyr demo in [1] we get:
> >
> >aspeed.io: unimplemented device write (size 4, offset 0x185128, value
> > 0x030f1ff1) <--
> >aspeed.io: unimple
On Wed, Dec 28, 2022 at 03:38:30PM +0100, Jason A. Donenfeld wrote:
> The setup_data links are appended to the compressed kernel image. Since
> the kernel image is typically loaded at 0x10, setup_data lives at
> `0x10 + compressed_size`, which does not get relocated during the
> kernel's bo
On Fri, Dec 30, 2022 at 12:34:56PM +0100, Philippe Mathieu-Daudé wrote:
> Add more Aspeed watchdog registers from [*].
>
> Since guests can righteously access them, log the access at
> 'unimplemented' level instead of 'guest-errors'.
>
> [*]
> https://github.com/AspeedTech-BMC/zephyr/blob/v00.01
Alexander,
On Fri, Dec 30, 2022 at 06:44:14PM +0100, Alexander Graf wrote:
> Hi Vitaly,
>
> This is a kvm kernel bug and should be fixed with the latest stable releases.
> Which kernel version are you running?
This is on latest v6.0 stable - 6.0.15.
Maybe there could be workaround for such sit
Hi Vitaly,
This is a kvm kernel bug and should be fixed with the latest stable releases.
Which kernel version are you running?
Thanks,
Alex
> Am 30.12.2022 um 15:30 schrieb Vitaly Chikunov :
>
> Hi,
>
> QEMU 7.2.0 when run on 32-bit x86 architecture fails with:
>
> i586$ qemu-system-i386
On Fri, Dec 30, 2022 at 6:01 PM Borislav Petkov wrote:
>
> On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> > >
> > > early console in extract_kernel
> > > input_data: 0x0be073a8
> > > input_len: 0
On 12/30/22 10:24, James Bottomley wrote:
From: James Bottomley
Instead of processing the tpmdev options using the old qemu options,
convert to the new visitor format which also allows the passing of
json on the command line.
Signed-off-by: James Bottomley
---
v4: add TpmConfiOptions
---
On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> >
> > early console in extract_kernel
> > input_data: 0x0be073a8
> > input_len: 0x008cfc43
> > output: 0x0100
> > output_len: 0x00
Mirroring the upstream gdb xml files, the two stack boundary
registers are separated out.
Signed-off-by: Richard Henderson
---
I did this thinking I would be fixing:
TESTbasic gdbstub support on microblaze
Truncated register 35 in remote 'g' packet
Traceback (most recent call last):
Er, .config attached now.
.config
Description: Binary data
Hi,
On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
> wrote:
> >Hi,
> >
> >Read this message in a fixed width text editor with a lot of columns.
> >
> >On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
> >>
On Thu, Dec 29, 2022 at 01:47:49PM +0100, Borislav Petkov wrote:
> On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> > As far as a crash... that sounds like a big and a pretty serious one at
> > that.
> >
> > Could you let me know what kernel you are using and how *exactly* you ar
On 30/12/22 15:57, Felipe Balbi wrote:
Olimex makes a series of low-cost STM32 boards. This commit introduces
the minimum setup to support SMT32-H405. See [1] for details
[1] https://www.olimex.com/Products/ARM/ST/STM32-H405/
Signed-off-by: Felipe Balbi
---
Changes since v1:
- Add a n
From: James Bottomley
The Microsoft Simulator (mssim) is the reference emulation platform
for the TCG TPM 2.0 specification.
https://github.com/Microsoft/ms-tpm-20-ref.git
It exports a fairly simple network socket based protocol on two
sockets, one for command (default 2321) and one for control
From: James Bottomley
Instead of processing the tpmdev options using the old qemu options,
convert to the new visitor format which also allows the passing of
json on the command line.
Signed-off-by: James Bottomley
---
v4: add TpmConfiOptions
---
backends/tpm/tpm_emulator.c| 24 -
From: James Bottomley
The requested feedback was to convert the tpmdev handler to being json
based, which requires rethreading all the backends. The good news is
this reduced quite a bit of code (especially as I converted it to
error_fatal handling as well, which removes the return status
thread
Hi,
The following patches pass checkpatch.pl and have been tested against
55745005e90a.
Felipe Balbi (2):
hw/arm/stm32f405: correctly describe the memory layout
hw/arm: Add Olimex H405
MAINTAINERS | 6 +++
configs/devices/arm-softmmu/default.mak | 1 +
docs/sys
STM32F405 has 128K of SRAM and another 64K of CCM (Core-coupled
Memory) at a different base address. Correctly describe the memory
layout to give existing FW images a chance to run unmodified.
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Felipe Balbi
---
Cha
Olimex makes a series of low-cost STM32 boards. This commit introduces
the minimum setup to support SMT32-H405. See [1] for details
[1] https://www.olimex.com/Products/ARM/ST/STM32-H405/
Signed-off-by: Felipe Balbi
---
Changes since v1:
- Add a note in stm32.rst
- Initialize def
From: "dengp...@chinatelecom.cn"
Now that migration already be supported, so remove the blocker.
Signed-off-by: dengp...@chinatelecom.cn
Signed-off-by: liuy...@chinatelecom.cn
---
ui/vdagent.c | 12
1 file changed, 12 deletions(-)
diff --git a/ui/vdagent.c b/ui/vdagent.c
index 1
From: "dengp...@chinatelecom.cn"
1. after live migration, copy/paste with vnc is not working. this is because:
1). vd->caps is not saved; this will leads wrong clipboard type is prased in
vdagent_clipboard_recv_grab;
2). vdagent isn`t register to qemu-clipboard; this will leads vdagent cannot
s
From: "dengp...@chinatelecom.cn"
Abstract vdagent registry logic into
vdagent_register_to_qemu_clipboard.
Note that trace log of vdagent_recv_caps also be added.
Signed-off-by: dengp...@chinatelecom.cn
Signed-off-by: liuy...@chinatelecom.cn
---
ui/trace-events | 1 +
ui/vdagent.c| 20 ++
From: "dengp...@chinatelecom.cn"
To support live migration, we made the following 2 modifications:
1. save the caps field of VDAgentChardev.
2. register vdagent to qemu-clipboard after
vm device state being reloaded during live migration.
Signed-off-by: dengp...@chinatelecom.cn
Signed-off-by
From: "dengp...@chinatelecom.cn"
Memory free should be done in vdagent_disconnect using
qemu_input_handler_unregister, replace qemu_input_handler_deactivate
with that.
Signed-off-by: dengp...@chinatelecom.cn
Signed-off-by: liuy...@chinatelecom.cn
---
ui/vdagent.c | 2 +-
1 file changed, 1 ins
Hi,
QEMU 7.2.0 when run on 32-bit x86 architecture fails with:
i586$ qemu-system-i386 -enable-kvm
qemu-system-i386: Could not install MSR_CORE_THREAD_COUNT handler: Success
i586$ qemu-system-x86_64 -enable-kvm
qemu-system-x86_64: Could not install MSR_CORE_THREAD_COUNT handler: Success
M
On Friday, December 30, 2022 10:01:47 AM CET Volker Rümelin wrote:
> Am 28.12.22 um 14:52 schrieb Christian Schoenebeck:
> > On Monday, December 26, 2022 4:08:37 PM CET Volker Rümelin wrote:
> >> Am 21.12.22 um 12:03 schrieb Christian Schoenebeck:
> >>> On Sunday, December 18, 2022 6:15:38 PM CET V
On Thursday, December 29, 2022 1:31:09 PM CET Philippe Mathieu-Daudé wrote:
> On 27/12/22 17:15, Christian Schoenebeck wrote:
> > While mouse is grabbed, window title contains a hint for the user what
> > keyboard keys to press to release the mouse. Make that hint text a bit
> > more user friendly
On Thursday, December 29, 2022 7:03:54 AM CET Shi, Guohuai wrote:
>
> > -Original Message-
> > From: Christian Schoenebeck
> > Sent: Wednesday, December 28, 2022 19:51
> > To: Greg Kurz ; qemu-devel@nongnu.org
> > Cc: Meng, Bin ; Shi, Guohuai
> >
> > Subject: Re: [PATCH v3 07/17] hw/9pfs
On 30/12/22 01:02, Richard Henderson wrote:
As in page_get_flags, we need to try again with the mmap
lock held if we fail a page lookup.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
accel/tcg/user-exec.c | 41 ++---
1 file chan
On 29/12/22 19:11, Daniel Henrique Barboza wrote:
The sifive_u, spike and virt machines are writing the 'bootargs' FDT
node during their respective create_fdt().
Given that bootargs is written only when '-append' is used, and this
option is only allowed with the '-kernel' option, which in turn i
On 29/12/22 19:11, Daniel Henrique Barboza wrote:
riscv_load_initrd() returns the initrd end addr while also writing a
'start' var to mark the addr start. These informations are being used
just to write the initrd FDT node. Every existing caller of
riscv_load_initrd() is writing the FDT in the sa
On 29/12/22 19:11, Daniel Henrique Barboza wrote:
This test is used to do a quick sanity check to ensure that we're able
to run the existing QEMU FW image.
'sifive_u', 'spike' and 'virt' riscv64 machines, and 'sifive_u' and
'virt' 32 bit machines are able to run the default RISCV64_BIOS_BIN |
RI
On 30/12/22 09:58, Bin Meng wrote:
On Fri, Dec 30, 2022 at 2:21 AM Daniel Henrique Barboza
wrote:
riscv_load_kernel() and riscv_load_initrd() works under the assumption
that 'kernel_filename' and 'filename' are not NULL.
We should do the same in riscv_load_firmware()
Can be done on top IMH
On 30/12/22 10:59, Tianrui Zhao wrote:
Change the default irq number of pch pic to 32, so that the irq
number of pch msi is 224(256 - 32), and move the 'PCH_PIC_IRQ_NUM'
macro to pci-host/ls7a.h and add prefix 'VIRT' on it to keep standard
format.
Signed-off-by: Tianrui Zhao
---
hw/intc/loong
On 29/12/22 12:49, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago
already, so we should finally do the next step and deprecate the
legacy CLI option, too.
Signed-off-by: Thomas Huth
---
v2:
- Rebased to current version from master branch / adjusted v
From: David Woodhouse
The xen_overlay device (and later similar devices for event channels and
grant tables) need to be instantiated. Do this from a kvm_type method on
the PC machine derivatives, since KVM is only way to support Xen emulation
for now.
Signed-off-by: David Woodhouse
---
hw/i386
From: David Woodhouse
For the shared info page and for grant tables, Xen shares its own pages
from the "Xen heap" to the guest. The guest requests that a given page
from a certain address space (XENMAPSPACE_shared_info, etc.) be mapped
to a given GPA using the XENMEM_add_to_physmap hypercall.
To
From: Joao Martins
Specifically add listing, injection of event channels.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
hmp-commands.hx | 29 ++
hw/i386/kvm/xen_evtchn.c | 83
hw/i386/kvm/xen_evtchn.h | 3 ++
moni
From: David Woodhouse
Xen has eight frames at 0xfeff8000 for this; we only really need two for
now and KVM puts the identity map at 0xfeffc000, so limit ourselves to
four.
Signed-off-by: David Woodhouse
---
include/sysemu/kvm_xen.h | 8
target/i386/kvm/xen-emu.c | 15 +++
On 30/12/22 12:34, Philippe Mathieu-Daudé wrote:
When booting the Zephyr demo in [1] we get:
aspeed.io: unimplemented device write (size 4, offset 0x185128, value
0x030f1ff1) <--
aspeed.io: unimplemented device write (size 4, offset 0x18512c, value
0x03f1)
This corresponds to this Z
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 78 +++
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/kvm/xen-emu.c | 16
3 files changed, 96 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_
On 30/12/22 10:59, Tianrui Zhao wrote:
With loongarch 7A1000 manual, irq number supported can be set
in PCH_PIC_INT_ID_HI register. This patch adds irq number property
for loongarch_pch_pic, so that virt machine can set different
irq number when pch_pic intc is added.
Signed-off-by: Tianrui Zhao
From: David Woodhouse
It calls an internal close_port() helper which will also be used from
EVTCHNOP_reset and will actually do the work to disconnect/unbind a port
once any of that is actually implemented in the first place.
That in turn calls a free_port() internal function which will be in
er
From: David Woodhouse
Xen will "latch" the guest's 32-bit or 64-bit ("long mode") setting when
the guest writes the MSR to fill in the hypercall page, or when the guest
sets the event channel callback in HVM_PARAM_CALLBACK_IRQ.
KVM handles the former and sets the kernel's long_mode flag accordin
From: Ankur Arora
The HVMOP_set_evtchn_upcall_vector hypercall sets the per-vCPU upcall
vector, to be delivered to the local APIC just like an MSI (with an EOI).
This takes precedence over the system-wide delivery method set by the
HVMOP_set_param hypercall with HVM_PARAM_CALLBACK_IRQ. It's used
From: Joao Martins
Additionally set XEN_INTERFACE_VERSION to most recent in order to
exercise the "new" event_channel_op.
Signed-off-by: Joao Martins
[dwmw2: Ditch event_channel_op_compat which was never available to HVM guests]
Signed-off-by: David Woodhouse
---
target/i386/kvm/xen-emu.c | 2
On 30/12/22 10:59, Tianrui Zhao wrote:
This patch adds irq number property for loongarch msi interrupt
controller, and remove hard coding irq number macro.
Signed-off-by: Tianrui Zhao
---
hw/intc/loongarch_pch_msi.c | 33 ++---
hw/loongarch/virt.c
From: David Woodhouse
Include basic support for setting HVM_PARAM_CALLBACK_IRQ to the global
vector method HVM_PARAM_CALLBACK_TYPE_VECTOR, which is handled in-kernel
by raising the vector whenever the vCPU's vcpu_info->evtchn_upcall_pending
flag is set.
Signed-off-by: David Woodhouse
---
hw/i3
On Fri, Dec 30, 2022 at 8:04 PM Daniel Henrique Barboza
wrote:
>
>
>
> On 12/30/22 06:05, Bin Meng wrote:
> > On Fri, Dec 30, 2022 at 2:47 AM Daniel Henrique Barboza
> > wrote:
> >> The microchip_icicle_kit, sifive_u, spike and virt boards are now doing
> >> the same steps when '-kernel' is used:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 69 +++
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 15 +
3 files changed, 86 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xe
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/meson.build | 1 +
hw/i386/kvm/xen_gnttab.c | 110 ++
hw/i386/kvm/xen_gnttab.h | 18 +++
hw/i386/pc.c | 2 +
target/i386/kvm/xen-emu.c | 3 ++
5 files changed, 13
From: Joao Martins
This is just meant to serve as an example on how we can implement
hypercalls. xen_version specifically since Qemu does all kind of
feature controllability. So handling that here seems appropriate.
Signed-off-by: Joao Martins
[dwmw2: Implement kvm_gva_rw() safely]
Signed-off-b
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_gnttab.c | 83 ++-
hw/i386/kvm/xen_overlay.c | 2 +-
hw/i386/kvm/xen_overlay.h | 2 +
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/hw/i386/kvm/xen_gnttab.c b/hw/i38
From: Joao Martins
Introduce support for emulating CPUID for Xen HVM guests. It doesn't make
sense to advertise the KVM leaves to a Xen guest, so do Xen unconditionally
when the xen-version machine property is set.
Signed-off-by: Joao Martins
[dwmw2: Obtain xen_version from KVM property, make i
From: Joao Martins
This means handling the new exit reason for Xen but still
crashing on purpose. As we implement each of the hypercalls
we will then return the right return code.
Signed-off-by: Joao Martins
[dwmw2: Add CPL to hypercall tracing, disallow hypercalls from CPL > 0]
Signed-off-by:
From: David Woodhouse
Add the array of virq ports to each vCPU so that we can deliver timers,
debug ports, etc. Global virqs are allocated against vCPU 0 initially,
but can be migrated to other vCPUs (when we implement that).
The kernel needs to know about VIRQ_TIMER in order to accelerate timer
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_gnttab.c | 19 +++
hw/i386/kvm/xen_gnttab.h | 2 ++
target/i386/kvm/xen-emu.c | 16 +++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/hw/i386/kvm/xen_gnttab.c b/hw/i386/kvm/
From: David Woodhouse
The provides the QEMU side of interdomain event channels, allowing events
to be sent to/from the guest.
The API mirrors libxenevtchn, and in time both this and the real Xen one
will be available through ops structures so that the PV backend drivers
can use the correct one a
From: David Woodhouse
Signed-off-by: David Woodhouse
---
accel/kvm/kvm-all.c | 1 +
include/sysemu/kvm_int.h | 1 +
include/sysemu/kvm_xen.h | 1 +
target/i386/kvm/kvm.c | 34 ++
target/i386/kvm/xen-emu.c | 6 ++
5 files changed, 43 insertions
From: Joao Martins
Introduce support for one shot and periodic mode of Xen PV timers,
whereby timer interrupts come through a special virq event channel
with deadlines being set through:
1) set_timer_op hypercall (only oneshot)
2) vcpu_op hypercall for {set,stop}_{singleshot,periodic}_timer
hype
From: David Woodhouse
They both do the same thing and just call sched_yield. This is enough to
stop the Linux guest panicking when running on a host kernel which doesn't
intercept SCHEDOP_poll and lets it reach userspace.
Signed-off-by: David Woodhouse
---
target/i386/kvm/xen-emu.c | 12 ++
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_gnttab.c | 31
hw/i386/kvm/xen_gnttab.h | 5
target/i386/kvm/xen-emu.c | 60 +++
3 files changed, 96 insertions(+)
diff --git a/hw/i386/kvm/xen_gnttab.c b/h
From: David Woodhouse
The XEN_EMU option will cover core Xen support in target/, which exists
only for x86 with KVM today but could theoretically also be implemented
on Arm/Aarch64 and with TCG or other accelerators. It will also cover
the support for architecture-independent grant table and even
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 40 +++
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 12
3 files changed, 54 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm
From: Joao Martins
In order to support Linux vdso in Xen.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
target/i386/cpu.h | 1 +
target/i386/kvm/xen-emu.c | 100 +-
target/i386/machine.c | 1 +
3 files changed, 90 insertions
From: Joao Martins
Handle the hypercall to set a per vcpu info, and also wire up the default
vcpu_info in the shared_info page for the first 32 vCPUs.
To avoid deadlock within KVM a vCPU thread must set its *own* vcpu_info
rather than it being set from the context in which the hypercall is
invok
From: David Woodhouse
The GSI callback (and later PCI_INTX) is a level triggered interrupt. It
is asserted when an event channel is delivered to vCPU0, and is supposed
to be cleared when the vcpu_info->evtchn_upcall_pending field for vCPU0
is cleared again.
Thankfully, Xen does *not* assert the
From: David Woodhouse
This adds the basic structure for maintaining the port table and reporting
the status of ports therein.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 106 ++
hw/i386/kvm/xen_evtchn.h | 3 ++
target/i386/kvm/xen-emu.c
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 29 +
hw/i386/kvm/xen_evtchn.h | 3 +++
target/i386/kvm/xen-emu.c | 17 +
3 files changed, 49 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen
From: David Woodhouse
The kvm_xen_inject_vcpu_callback_vector() function will either deliver
the per-vCPU local APIC vector (as an MSI), or just kick the vCPU out
of the kernel to trigger KVM's automatic delivery of the global vector.
Support for asserting the GSI/PCI_INTX callbacks will come lat
From: Joao Martins
This is when guest queries for support for HVMOP_pagetable_dying.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
target/i386/kvm/xen-emu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 32
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 15 +++
3 files changed, 49 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen
From: Joao Martins
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/xen/xen-legacy-backend.c | 40 +
include/hw/xen/xen-legacy-backend.h | 3 +++
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/hw
From: David Woodhouse
This just initializes the basic Xen support in KVM for now. Only permitted
on TYPE_PC_MACHINE because that's where the sysbus devices for Xen heap
overlay, event channel, grant tables and other stuff will exist. There's
no point having the basic hypercall support if nothing
Round 5, in which it gains a XenStore implementation. This just returns
ENOSYS to every request for now, but that's enough to let older Linux
guests boot, and let the XTF tests run.
As noted, I'd like to hook that up to a real xenstored via the UNIX
socket and an XS_SU command to let that connecti
From: Joao Martins
Allow guest to setup the vcpu runstates which is used as
steal clock.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
target/i386/cpu.h | 1 +
target/i386/kvm/xen-emu.c | 57 +++
target/i386/machine.c | 1 +
3
From: David Woodhouse
There are (at least) three different vCPU ID number spaces. One is the
internal KVM vCPU index, based purely on which vCPU was chronologically
created in the kernel first. If userspace threads are all spawned and
create their KVM vCPUs in essentially random order, then the K
From: Joao Martins
It allows to shutdown itself via hypercall with any of the 3 reasons:
1) self-reboot
2) shutdown
3) crash
Implementing SCHEDOP_shutdown sub op let us handle crashes gracefully rather
than leading to triple faults if it remains unimplemented.
In addition, the SHUTDOWN_so
From: David Woodhouse
Signed-off-by: David Woodhouse
---
target/i386/kvm/xen-compat.h | 24 +
target/i386/kvm/xen-emu.c| 69
2 files changed, 93 insertions(+)
diff --git a/target/i386/kvm/xen-compat.h b/target/i386/kvm/xen-compat.h
index 0b7
From: David Woodhouse
Extract requests, return ENOSYS to all of them. This is enough to allow
older Linux guests to boot, as they need *something* back but it doesn't
matter much what.
In the first instance we're likely to wire this up over a UNIX socket to
an actual xenstored implementation, bu
From: David Woodhouse
The hookup to event channel is a bit of a special case hack right now; as
we make this work for real PV driver back ends, that will be implemented
for the general case of Dom0 ports binding to DomU.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/meson.build| 1 +
hw
From: Joao Martins
Such that PCI passthrough devices work for Xen emulated guests.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/xen/xen_platform.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/hw/i3
From: Ankur Arora
This is the hook for adding the HVM_PARAM_CALLBACK_IRQ parameter in a
subsequent commit.
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
[dwmw2: Split out from another commit]
Signed-off-by: David Woodhouse
---
target/i386/kvm/xen-emu.c | 33 +
From: Joao Martins
The only thing we need to handle on KVM side is to change the
pfn from R/W to R/O.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
hw/i386/xen/meson.build| 5 -
hw/i386/xen/xen_platform.c | 39 +-
2 files changed,
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 180 ++
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/kvm/xen-emu.c | 12 +++
3 files changed, 194 insertions(+)
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_ev
From: David Woodhouse
This finally comes with a mechanism for actually injecting events into
the guest vCPU, with all the atomic-test-and-set that's involved in
setting the bit in the shinfo, then the index in the vcpu_info, and
injecting either the lapic vector as MSI, or letting KVM inject the
1 - 100 of 128 matches
Mail list logo
