Re: [PATCH 0/5] migration: Modified 'migrate' QAPI command for migration
On 26/12/22 11:03 am, Het Gala wrote: Current QAPI 'migrate' command design (for initiating a migration stream) contains information regarding different migrate transport mechanism (tcp / unix / exec), dest-host IP address, and binding port number in form of a string. Thus the design does seem to have some design issues. Some of the issues, stated below are: 1. Use of string URIs is a data encoding scheme within a data encoding scheme. QEMU code should directly be able to work with the results from QAPI, without resorting to do a second level of parsing (eg. socket_parse()). 2. For features / parameters related to migration, the migration tunables needs to be defined and updated upfront. For example, 'migrate-set-capability' and 'migrate-set-parameter' is required to enable multifd capability and multifd-number of channels respectively. Instead, 'Multifd-channels' can directly be represented as a single additional parameter to 'migrate' QAPI. 'migrate-set-capability' and 'migrate-set-parameter' commands could be used for runtime tunables that need setting after migration has already started. The current patchset focuses on solving the first problem of multi-level encoding of URIs. The patch defines 'migrate' command as a QAPI discriminated union for the various transport backends (like socket, exec and rdma), and on basis of transport backends, different migration parameters are defined. (uri) string --> (channel) Channel-type Transport-type Migration parameters based on transport type I hope all of you had nice a lovely christmas :) and wish you all a beautiful new year!! Just a gentle reminder for patch review. This patchset series focuses on the idea of modifying qemu 'migration' QAPI syntax into a well defined data structure. Hoping for suggestions and active discussions on the patchset series from all the maintainers. Regards, Het Gala
Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data
On Mon, Jan 02, 2023 at 07:01:50AM +0100, Borislav Petkov wrote: > On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote: > > It would probably be a good idea to add a "maximum physical address for > > initrd/setup_data/cmdline" field to struct kernel_info, though. It appears > > right now that those fields are being identity-mapped in the decompressor, > > and that means that if 48-bit addressing is used, physical memory may extend > > past the addressable range. > > Yeah, we will probably need that too. > > Btw, looka here - it can't get any more obvious than that after dumping > setup_data too: > > early console in setup code > early console in extract_kernel > input_data: 0x040f92bf > input_len: 0x00f1c325 > output: 0x0100 > output_len: 0x03c5e7d8 > kernel_total_size: 0x04428000 > needed_size: 0x0460 > boot_params->hdr.setup_data: 0x010203b0 > trampoline_32bit: 0x0009d000 > > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > > > Aligning them vertically: > > output: 0x0100 > output_len: 0x03c5e7d8 > kernel_total_size:0x04428000 > needed_size: 0x0460 > boot_params->hdr.setup_data: 0x010203b0 Ok, waait a minute: Field name: pref_address Type: read (reloc) Offset/size:0x258/8 Protocol: 2.10+ This field, if nonzero, represents a preferred load address for the kernel. A relocating bootloader should attempt to load at this address if possible. A non-relocatable kernel will unconditionally move itself and to run at this address. so a kernel loader (qemu in this case) already knows where the kernel goes: boot_params->hdr.setup_data: 0x01020450 boot_params->hdr.pref_address: 0x0100 ^ now, considering that same kernel loader (qemu) knows how big that kernel is: kernel_total_size: 0x04428000 should that loader *not* put anything that the kernel will use in the range pref_addr + kernel_total_size ? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data
On Sat, Dec 31, 2022 at 07:31:21PM -0800, H. Peter Anvin wrote: > It would probably be a good idea to add a "maximum physical address for > initrd/setup_data/cmdline" field to struct kernel_info, though. It appears > right now that those fields are being identity-mapped in the decompressor, > and that means that if 48-bit addressing is used, physical memory may extend > past the addressable range. Yeah, we will probably need that too. Btw, looka here - it can't get any more obvious than that after dumping setup_data too: early console in setup code early console in extract_kernel input_data: 0x040f92bf input_len: 0x00f1c325 output: 0x0100 output_len: 0x03c5e7d8 kernel_total_size: 0x04428000 needed_size: 0x0460 boot_params->hdr.setup_data: 0x010203b0 trampoline_32bit: 0x0009d000 Decompressing Linux... Parsing ELF... done. Booting the kernel. Aligning them vertically: output: 0x0100 output_len: 0x03c5e7d8 kernel_total_size: 0x04428000 needed_size:0x0460 boot_params->hdr.setup_data:0x010203b0 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] net: Increase L2TPv3 buffer to fit jumboframes
+qemu-trivial On Fri, Dec 30, 2022, 21:27 Christian Svensson wrote: > 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 Svensson > --- > net/l2tpv3.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/l2tpv3.c b/net/l2tpv3.c > index 5852e42738..3d5c6d11d3 100644 > --- a/net/l2tpv3.c > +++ b/net/l2tpv3.c > @@ -42,7 +42,7 @@ > */ > > #define BUFFER_ALIGN sysconf(_SC_PAGESIZE) > -#define BUFFER_SIZE 2048 > +#define BUFFER_SIZE 16384 > #define IOVSIZE 2 > #define MAX_L2TPV3_MSGCNT 64 > #define MAX_L2TPV3_IOVCNT (MAX_L2TPV3_MSGCNT * IOVSIZE) > -- > 2.36.2 > >
Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data
On Sat, Dec 31, 2022 at 07:21:06PM -0800, H. Peter Anvin wrote:
> As far as the decompression itself goes, it should only a problem if we are
> using physical KASLR since otherwise the kernel has a guaranteed safe zone
> already allocated by the boot loader. However, if physical KASLR is in use,
No KASLR in Jason's config AFAICT:
$ grep RANDOMIZE .config
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET=y
CONFIG_RANDOMIZE_KSTACK_OFFSET=y
# CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT is not set
> then the decompressor needs to know everything there is to know about the
> memory map.
Yeah, we do have that but as you folks establish later in the thread, those
setup_data regions would need to be avoided too. ;-\
> However, there also seems to be some kind of interaction with AMD SEV-SNP.
>
>
> The bug appears to have been introduced by:
>
> b57feed2cc2622ae14b2fa62f19e973e5e0a60cf
> x86/compressed/64: Add identity mappings for setup_data entries
> https://lore.kernel.org/r/tycpr01mb694815cd815e98945f63c99183...@tycpr01mb6948.jpnprd01.prod.outlook.com
>
> ... which was included in version 5.19, so it is relatively recent.
Right. We need that for the CC blob:
b190a043c49a ("x86/sev: Add SEV-SNP feature detection/setup")
> For a small amount of setup_data, the solution of just putting it next to
> the command line makes a lot of sense, and should be safe indefinitely.
Ok.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
[PATCH] linux-user: fix bug about incorrect base addresss of idt and gdt on i386 and x86_64
From: fanwenjie
On linux user mode, CPUX86State::idt::base and CPUX86State::gdt::base from
Different CPUX86State Objects have same value, It is incorrect! Every
CPUX86State::idt::base and Every CPUX86State::gdt::base Must points to
independent memory space.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1405
Signed-off-by: fanwenjie
---
linux-user/i386/cpu_loop.c | 10 ++
linux-user/main.c | 11 +++
2 files changed, 21 insertions(+)
diff --git a/linux-user/i386/cpu_loop.c b/linux-user/i386/cpu_loop.c
index 865413c08f..1f23bc5e3a 100644
--- a/linux-user/i386/cpu_loop.c
+++ b/linux-user/i386/cpu_loop.c
@@ -314,8 +314,18 @@ void cpu_loop(CPUX86State *env)
}
}
+static void target_cpu_free(void *obj)
+{
+CPUArchState* env = ((CPUState*)obj)->env_ptr;
+target_munmap(env->idt.base, sizeof(uint64_t) * (env->idt.limit + 1));
+target_munmap(env->gdt.base, sizeof(uint64_t) * TARGET_GDT_ENTRIES);
+g_free(obj);
+}
+
void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs)
{
+CPUState* cpu = env_cpu(env);
+OBJECT(cpu)->free = target_cpu_free;
env->cr[0] = CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK;
env->hflags |= HF_PE_MASK | HF_CPL_MASK;
if (env->features[FEAT_1_EDX] & CPUID_SSE) {
diff --git a/linux-user/main.c b/linux-user/main.c
index a17fed045b..2276040548 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -234,6 +234,17 @@ CPUArchState *cpu_copy(CPUArchState *env)
new_cpu->tcg_cflags = cpu->tcg_cflags;
memcpy(new_env, env, sizeof(CPUArchState));
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+new_env->gdt.base = target_mmap(0, sizeof(uint64_t) * TARGET_GDT_ENTRIES,
+PROT_READ|PROT_WRITE,
+MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+new_env->idt.base = target_mmap(0, sizeof(uint64_t) * (env->idt.limit + 1),
+PROT_READ|PROT_WRITE,
+MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+memcpy((void*)new_env->gdt.base, (void*)env->gdt.base, sizeof(uint64_t) *
TARGET_GDT_ENTRIES);
+memcpy((void*)new_env->idt.base, (void*)env->idt.base, sizeof(uint64_t) *
(env->idt.limit + 1));
+OBJECT(new_cpu)->free = OBJECT(cpu)->free;
+#endif
/* Clone all break/watchpoints.
Note: Once we support ptrace with hw-debug register access, make sure
--
2.34.1
[PATCH] vmnet: stop recieving events when VM is stopped
When the VM is stopped using the HMP command "stop", soon the handler will
stop reading from the vmnet interface. This causes a flood of
`VMNET_INTERFACE_PACKETS_AVAILABLE` events to arrive and puts the host CPU
at 100%. We fix this by removing the event handler from vmnet when the VM
is no longer in a running state and restore it when we return to a running
state.
Signed-off-by: Joelle van Dyne
---
net/vmnet_int.h| 2 ++
net/vmnet-common.m | 48 +-
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/net/vmnet_int.h b/net/vmnet_int.h
index adf6e8c20d..ffba92108f 100644
--- a/net/vmnet_int.h
+++ b/net/vmnet_int.h
@@ -46,6 +46,8 @@ typedef struct VmnetState {
int packets_send_end_pos;
struct iovec iov_buf[VMNET_PACKETS_LIMIT];
+
+VMChangeStateEntry *change;
} VmnetState;
const char *vmnet_status_map_str(vmnet_return_t status);
diff --git a/net/vmnet-common.m b/net/vmnet-common.m
index 2cb60b9ddd..2958283485 100644
--- a/net/vmnet-common.m
+++ b/net/vmnet-common.m
@@ -17,6 +17,7 @@
#include "clients.h"
#include "qemu/error-report.h"
#include "qapi/error.h"
+#include "sysemu/runstate.h"
#include
#include
@@ -242,6 +243,35 @@ static void vmnet_bufs_init(VmnetState *s)
}
}
+/**
+ * Called on state change to un-register/re-register handlers
+ */
+static void vmnet_vm_state_change_cb(void *opaque, bool running, RunState
state)
+{
+VmnetState *s = opaque;
+
+if (running) {
+vmnet_interface_set_event_callback(
+s->vmnet_if,
+VMNET_INTERFACE_PACKETS_AVAILABLE,
+s->if_queue,
+^(interface_event_t event_id, xpc_object_t event) {
+assert(event_id == VMNET_INTERFACE_PACKETS_AVAILABLE);
+/*
+ * This function is being called from a non qemu thread, so
+ * we only schedule a BH, and do the rest of the io completion
+ * handling from vmnet_send_bh() which runs in a qemu context.
+ */
+qemu_bh_schedule(s->send_bh);
+});
+} else {
+vmnet_interface_set_event_callback(
+s->vmnet_if,
+VMNET_INTERFACE_PACKETS_AVAILABLE,
+NULL,
+NULL);
+}
+}
int vmnet_if_create(NetClientState *nc,
xpc_object_t if_desc,
@@ -329,19 +359,9 @@ int vmnet_if_create(NetClientState *nc,
s->packets_send_current_pos = 0;
s->packets_send_end_pos = 0;
-vmnet_interface_set_event_callback(
-s->vmnet_if,
-VMNET_INTERFACE_PACKETS_AVAILABLE,
-s->if_queue,
-^(interface_event_t event_id, xpc_object_t event) {
-assert(event_id == VMNET_INTERFACE_PACKETS_AVAILABLE);
-/*
- * This function is being called from a non qemu thread, so
- * we only schedule a BH, and do the rest of the io completion
- * handling from vmnet_send_bh() which runs in a qemu context.
- */
-qemu_bh_schedule(s->send_bh);
-});
+vmnet_vm_state_change_cb(s, 1, RUN_STATE_RUNNING);
+
+s->change = qemu_add_vm_change_state_handler(vmnet_vm_state_change_cb, s);
return 0;
}
@@ -356,6 +376,8 @@ void vmnet_cleanup_common(NetClientState *nc)
return;
}
+vmnet_vm_state_change_cb(s, 0, RUN_STATE_SHUTDOWN);
+qemu_del_vm_change_state_handler(s->change);
if_stopped_sem = dispatch_semaphore_create(0);
vmnet_stop_interface(
s->vmnet_if,
--
2.28.0
Re: [PATCH v2 2/3] hw/mips/malta: Set PIIX4 IRQ routes in embedded bootloader
Am 31. Dezember 2022 13:44:00 UTC schrieb "Philippe Mathieu-Daudé"
:
>On 31/12/22 10:53, Bernhard Beschow wrote:
>>
>>
>> Am 21. November 2022 15:34:05 UTC schrieb Bernhard Beschow
>> :
>>>
>>>
>>> Am 27. Oktober 2022 20:47:19 UTC schrieb "Philippe Mathieu-Daudé"
>>> :
Linux kernel expects the northbridge & southbridge chipsets
configured by the BIOS firmware. We emulate that by writing
a tiny bootloader code in write_bootloader().
Upon introduction in commit 5c2b87e34d ("PIIX4 support"),
the PIIX4 configuration space included values specific to
the Malta board.
Set the Malta-specific IRQ routing values in the embedded
bootloader, so the next commit can remove the Malta specific
bits from the PIIX4 PCI-ISA bridge and make it generic
(matching the real hardware).
Signed-off-by: Philippe Mathieu-Daudé
---
FIXME: Missing the nanoMIPS counter-part!
>>>
>>> Who will be taking care of this? I have absolutely no clue how the
>>> write_bootloader functions work, so I don't see how to fix it.
>>
>> Ping
>
>This comment has been taken care of:
>https://lore.kernel.org/qemu-devel/a3c3f639-dbb1-88a7-43fe-547a234c5...@linaro.org/
Ah, now I see where this is going.
>However while testing the MIPS pull request I prepared I
>found a bug in the GT64120 which I'm trying to fix since
>various days... Unfortunately your series depends on it,
>so this is a blocking issue. Sorry for this long delay...
Don't worry.
How can the bug be reproduced? Is there a test run in the CI? Note that I get a
404 when trying to access
https://gitlab.com/philmd/qemu/-/commits/mips-testing/ .
Best regards,
Bernhard
>
>Phil.
[PATCH v6] xen/pt: reserve PCI slot 2 for Intel igd-passthru
Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
as noted in docs/igd-assign.txt in the Qemu source code.
Currently, when the xl toolstack is used to configure a Xen HVM guest with
Intel IGD passthrough to the guest with the Qemu upstream device model,
a Qemu emulated PCI device will occupy slot 2 and the Intel IGD will occupy
a different slot. This problem often prevents the guest from booting.
The only available workaround is not good: Configure Xen HVM guests to use
the old and no longer maintained Qemu traditional device model available
from xenbits.xen.org which does reserve slot 2 for the Intel IGD.
To implement this feature in the Qemu upstream device model for Xen HVM
guests, introduce the following new functions, types, and macros:
* XEN_PT_DEVICE_CLASS declaration, based on the existing TYPE_XEN_PT_DEVICE
* XEN_PT_DEVICE_GET_CLASS macro helper function for XEN_PT_DEVICE_CLASS
* typedef XenPTQdevRealize function pointer
* XEN_PCI_IGD_SLOT_MASK, the value of slot_reserved_mask to reserve slot 2
* xen_igd_reserve_slot and xen_igd_clear_slot functions
The new xen_igd_reserve_slot function uses the existing slot_reserved_mask
member of PCIBus to reserve PCI slot 2 for Xen HVM guests configured using
the xl toolstack with the gfx_passthru option enabled, which sets the
igd-passthru=on option to Qemu for the Xen HVM machine type.
The new xen_igd_reserve_slot function also needs to be implemented in
hw/xen/xen_pt_stub.c to prevent FTBFS during the link stage for the case
when Qemu is configured with --enable-xen and --disable-xen-pci-passthrough,
in which case it does nothing.
The new xen_igd_clear_slot function overrides qdev->realize of the parent
PCI device class to enable the Intel IGD to occupy slot 2 on the PCI bus
since slot 2 was reserved by xen_igd_reserve_slot when the PCI bus was
created in hw/i386/pc_piix.c for the case when igd-passthru=on.
Move the call to xen_host_pci_device_get, and the associated error
handling, from xen_pt_realize to the new xen_igd_clear_slot function to
initialize the device class and vendor values which enables the checks for
the Intel IGD to succeed. The verification that the host device is an
Intel IGD to be passed through is done by checking the domain, bus, slot,
and function values as well as by checking that gfx_passthru is enabled,
the device class is VGA, and the device vendor in Intel.
Signed-off-by: Chuck Zmudzinski
---
Notes that might be helpful to reviewers of patched code in hw/xen:
The new functions and types are based on recommendations from Qemu docs:
https://qemu.readthedocs.io/en/latest/devel/qom.html
Notes that might be helpful to reviewers of patched code in hw/i386:
The small patch to hw/i386/pc_piix.c is protected by CONFIG_XEN so it does
not affect builds that do not have CONFIG_XEN defined.
xen_igd_gfx_pt_enabled() in the patched hw/i386/pc_piix.c file is an
existing function that is only true when Qemu is built with
xen-pci-passthrough enabled and the administrator has configured the Xen
HVM guest with Qemu's igd-passthru=on option.
v2: Remove From: tag at top of commit message
v3: Changed the test for the Intel IGD in xen_igd_clear_slot:
if (is_igd_vga_passthrough(>real_device) &&
(s->real_device.vendor_id == PCI_VENDOR_ID_INTEL)) {
is changed to
if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
&& (s->hostaddr.function == 0)) {
I hoped that I could use the test in v2, since it matches the
other tests for the Intel IGD in Qemu and Xen, but those tests
do not work because the necessary data structures are not set with
their values yet. So instead use the test that the administrator
has enabled gfx_passthru and the device address on the host is
02.0. This test does detect the Intel IGD correctly.
v4: Use brchu...@aol.com instead of brchu...@netscape.net for the author's
email address to match the address used by the same author in commits
be9c61da and c0e86b76
Change variable for XEN_PT_DEVICE_CLASS: xptc changed to xpdc
v5: The patch of xen_pt.c was re-worked to allow a more consistent test
for the Intel IGD that uses the same criteria as in other places.
This involved moving the call to xen_host_pci_device_get from
xen_pt_realize to xen_igd_clear_slot and updating the checks for the
Intel IGD in xen_igd_clear_slot:
if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
&& (s->hostaddr.function == 0)) {
is changed to
if (is_igd_vga_passthrough(>real_device) &&
s->real_device.domain == 0 && s->real_device.bus == 0 &&
s->real_device.dev == 2 && s->real_device.func == 0 &&
s->real_device.vendor_id == PCI_VENDOR_ID_INTEL) {
Added an explanation for the move of xen_host_pci_device_get from
xen_pt_realize to xen_igd_clear_slot to the commit message.
Rebase.
v6: Fix logging by removing these lines from the move from xen_pt_realize
to
[PATCH v5] xen/pt: reserve PCI slot 2 for Intel igd-passthru
Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
as noted in docs/igd-assign.txt in the Qemu source code.
Currently, when the xl toolstack is used to configure a Xen HVM guest with
Intel IGD passthrough to the guest with the Qemu upstream device model,
a Qemu emulated PCI device will occupy slot 2 and the Intel IGD will occupy
a different slot. This problem often prevents the guest from booting.
The only available workaround is not good: Configure Xen HVM guests to use
the old and no longer maintained Qemu traditional device model available
from xenbits.xen.org which does reserve slot 2 for the Intel IGD.
To implement this feature in the Qemu upstream device model for Xen HVM
guests, introduce the following new functions, types, and macros:
* XEN_PT_DEVICE_CLASS declaration, based on the existing TYPE_XEN_PT_DEVICE
* XEN_PT_DEVICE_GET_CLASS macro helper function for XEN_PT_DEVICE_CLASS
* typedef XenPTQdevRealize function pointer
* XEN_PCI_IGD_SLOT_MASK, the value of slot_reserved_mask to reserve slot 2
* xen_igd_reserve_slot and xen_igd_clear_slot functions
The new xen_igd_reserve_slot function uses the existing slot_reserved_mask
member of PCIBus to reserve PCI slot 2 for Xen HVM guests configured using
the xl toolstack with the gfx_passthru option enabled, which sets the
igd-passthru=on option to Qemu for the Xen HVM machine type.
The new xen_igd_reserve_slot function also needs to be implemented in
hw/xen/xen_pt_stub.c to prevent FTBFS during the link stage for the case
when Qemu is configured with --enable-xen and --disable-xen-pci-passthrough,
in which case it does nothing.
The new xen_igd_clear_slot function overrides qdev->realize of the parent
PCI device class to enable the Intel IGD to occupy slot 2 on the PCI bus
since slot 2 was reserved by xen_igd_reserve_slot when the PCI bus was
created in hw/i386/pc_piix.c for the case when igd-passthru=on.
Move the call to xen_host_pci_device_get, and the associated error
handling, from xen_pt_realize to the new xen_igd_clear_slot function to
initialize the device class and vendor values which enables the checks for
the Intel IGD to succeed. The verification that the host device is an
Intel IGD to be passed through is done by checking the domain, bus, slot,
and function values as well as by checking that gfx_passthru is enabled,
the device class is VGA, and the device vendor in Intel.
Signed-off-by: Chuck Zmudzinski
---
Notes that might be helpful to reviewers of patched code in hw/xen:
The new functions and types are based on recommendations from Qemu docs:
https://qemu.readthedocs.io/en/latest/devel/qom.html
Notes that might be helpful to reviewers of patched code in hw/i386:
The small patch to hw/i386/pc_piix.c is protected by CONFIG_XEN so it does
not affect builds that do not have CONFIG_XEN defined.
xen_igd_gfx_pt_enabled() in the patched hw/i386/pc_piix.c file is an
existing function that is only true when Qemu is built with
xen-pci-passthrough enabled and the administrator has configured the Xen
HVM guest with Qemu's igd-passthru=on option.
v2: Remove From: tag at top of commit message
v3: Changed the test for the Intel IGD in xen_igd_clear_slot:
if (is_igd_vga_passthrough(>real_device) &&
(s->real_device.vendor_id == PCI_VENDOR_ID_INTEL)) {
is changed to
if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
&& (s->hostaddr.function == 0)) {
I hoped that I could use the test in v2, since it matches the
other tests for the Intel IGD in Qemu and Xen, but those tests
do not work because the necessary data structures are not set with
their values yet. So instead use the test that the administrator
has enabled gfx_passthru and the device address on the host is
02.0. This test does detect the Intel IGD correctly.
v4: Use brchu...@aol.com instead of brchu...@netscape.net for the author's
email address to match the address used by the same author in commits
be9c61da and c0e86b76
Change variable for XEN_PT_DEVICE_CLASS: xptc changed to xpdc
v5: The patch of xen_pt.c was re-worked to allow a more consistent test
for the Intel IGD that uses the same criteria as in other places.
This involved moving the call to xen_host_pci_device_get from
xen_pt_realize to xen_igd_clear_slot and updating the checks for the
Intel IGD in xen_igd_clear_slot:
if (xen_igd_gfx_pt_enabled() && (s->hostaddr.slot == 2)
&& (s->hostaddr.function == 0)) {
is changed to
if (is_igd_vga_passthrough(>real_device) &&
s->real_device.domain == 0 && s->real_device.bus == 0 &&
s->real_device.dev == 2 && s->real_device.func == 0 &&
s->real_device.vendor_id == PCI_VENDOR_ID_INTEL) {
Added an explanation for the move of xen_host_pci_device_get from
xen_pt_realize to xen_igd_clear_slot to the commit message.
Rebase.
hw/i386/pc_piix.c| 3 +++
hw/xen/xen_pt.c | 56
Re: [PATCH 2/4] target/m68k: pass sign directly into make_quotient()
On 1/1/23 09:26, Laurent Vivier wrote:
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit :
This enables the quotient parameter to be changed from int32_t to uint32_t and
also allows the extra sign logic in make_quotient() to be removed.
Signed-off-by: Mark Cave-Ayland
---
target/m68k/fpu_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index 0932c464fd..ae839785fa 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -515,15 +515,8 @@ uint32_t HELPER(fmovemd_ld_postinc)(CPUM68KState *env,
uint32_t addr,
return fmovem_postinc(env, addr, mask, cpu_ld_float64_ra);
}
-static void make_quotient(CPUM68KState *env, int32_t quotient)
+static void make_quotient(CPUM68KState *env, int sign, uint32_t quotient)
{
- int sign;
-
- sign = quotient < 0;
- if (sign) {
- quotient = -quotient;
- }
-
quotient = (sign << 7) | (quotient & 0x7f);
env->fpsr = (env->fpsr & ~FPSR_QT_MASK) | (quotient << FPSR_QT_SHIFT);
}
@@ -536,7 +529,8 @@ void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg
*val1)
return;
}
- make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+ make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
@@ -547,7 +541,8 @@ void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg
*val1)
return;
}
- make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+ make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(fgetexp)(CPUM68KState *env, FPReg *res, FPReg *val)
I think you need an "abs(floatx80_to_int32())" in both cases as you do in PATCH
4
Or in fact
sign = extractFloatx80Sign(res);
quot = floatx80_to_int32(floatx80_abs(res->d), status);
make_quotient(env, sign, quot);
r~
Re: [PATCH 4/4] target/m68k: fix FPSR quotient byte for frem instruction
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit : The FPSR quotient byte should be set to the value of the quotient and not the result. Manually calculate the quotient in the frem helper in round to nearest even mode (note this is different from the quotient calculated internally for fmod), and use it to set the quotient byte accordingly. Signed-off-by: Mark Cave-Ayland Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1314 --- target/m68k/fpu_helper.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) Reviewed-by: Laurent Vivier
Re: [PATCH 2/4] target/m68k: pass sign directly into make_quotient()
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit :
This enables the quotient parameter to be changed from int32_t to uint32_t and
also allows the extra sign logic in make_quotient() to be removed.
Signed-off-by: Mark Cave-Ayland
---
target/m68k/fpu_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index 0932c464fd..ae839785fa 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -515,15 +515,8 @@ uint32_t HELPER(fmovemd_ld_postinc)(CPUM68KState *env,
uint32_t addr,
return fmovem_postinc(env, addr, mask, cpu_ld_float64_ra);
}
-static void make_quotient(CPUM68KState *env, int32_t quotient)
+static void make_quotient(CPUM68KState *env, int sign, uint32_t quotient)
{
-int sign;
-
-sign = quotient < 0;
-if (sign) {
-quotient = -quotient;
-}
-
quotient = (sign << 7) | (quotient & 0x7f);
env->fpsr = (env->fpsr & ~FPSR_QT_MASK) | (quotient << FPSR_QT_SHIFT);
}
@@ -536,7 +529,8 @@ void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
return;
}
-make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
@@ -547,7 +541,8 @@ void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
return;
}
-make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(fgetexp)(CPUM68KState *env, FPReg *res, FPReg *val)
I think you need an "abs(floatx80_to_int32())" in both cases as you do in PATCH
4
Thanks,
Laurent
Re: [PATCH 3/4] target/m68k: fix FPSR quotient byte for fmod instruction
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit : The FPSR quotient byte should be set to the value of the quotient and not the result. Switch from using floatx80_mod() to floatx80_modrem() which returns the quotient as a uint64_t which can be used for the quotient byte. Signed-off-by: Mark Cave-Ayland --- target/m68k/fpu_helper.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Reviewed-by: Laurent Vivier
Re: [PATCH 1/4] target/m68k: pass quotient directly into make_quotient()
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit : Signed-off-by: Mark Cave-Ayland --- target/m68k/fpu_helper.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) Reviewed-by: Laurent Vivier
Re: [PATCH 2/4] target/m68k: pass sign directly into make_quotient()
Le 01/01/2023 à 15:43, Mark Cave-Ayland a écrit : This enables the quotient parameter to be changed from int32_t to uint32_t and also allows the extra sign logic in make_quotient() to be removed. Signed-off-by: Mark Cave-Ayland --- target/m68k/fpu_helper.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) Reviewed-by: Laurent Vivier
Re: [PATCH] linux-user: fix bug about incorrect base addresss of idt and gdt on i386 and x86_64
fa...@mail.ustc.edu.cn writes:
> From 4601a624f40b2c89e7df2dec1adffb4f4308ba2d Mon Sep 17 00:00:00 2001
> From: fanwenjie
> Date: Sun, 1 Jan 2023 23:13:34 +0800
> Subject: [PATCH] linux-user: fix bug about incorrect base addresss of idt and
> gdt on i386 and x86_64
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1405
> Signed-off-by: fanwenjie
> ---
> linux-user/main.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index a17fed045b..5d673c95b3 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -171,6 +171,12 @@ void fork_end(int child)
>
> __thread CPUState *thread_cpu;
>
> +#if defined(TARGET_I386) || defined(TARGET_X86_64)
> +#include
> +__thread alignas(TARGET_PAGE_SIZE) static uint64_t
> gdt_base[TARGET_GDT_ENTRIES];
> +__thread alignas(TARGET_PAGE_SIZE) static uint64_t idt_base[TARGET_PAGE_SIZE
> / sizeof(uint64_t)];
> +#endif
> +
> bool qemu_cpu_is_self(CPUState *cpu)
> {
> return thread_cpu == cpu;
> @@ -235,6 +241,13 @@ CPUArchState *cpu_copy(CPUArchState *env)
> new_cpu->tcg_cflags = cpu->tcg_cflags;
> memcpy(new_env, env, sizeof(CPUArchState));
>
> +#if defined(TARGET_I386) || defined(TARGET_X86_64)
> +memcpy(idt_base, (void*)new_env->idt.base, sizeof(uint64_t) *
> (new_env->idt.limit + 1));
> +memcpy(gdt_base, (void*)new_env->gdt.base, sizeof(uint64_t) *
> TARGET_GDT_ENTRIES);
> +new_env->idt.base = (target_ulong)idt_base;
> +new_env->gdt.base = (target_ulong)gdt_base;
> +#endif
> +
This is the wrong place to copy target specific bits of code. I think
this belongs with cpu_clone_regs_child and the gdt/idt structures in
linux-user/i386/cpu_loop.c I think.
> /* Clone all break/watchpoints.
> Note: Once we support ptrace with hw-debug register access, make sure
> BP_CPU break/watchpoints are handled correctly on clone. */
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Recall: [PATCH] linux-user: fix bug about incorrect base addresss of idt and gdt on i386 and x86_64
The Patch has some problem, Please RECALL it!
-原始邮件-
发件人:fa...@mail.ustc.edu.cn
发送时间:2023-01-01 23:57:06 (星期日)
收件人: qemu-devel@nongnu.org
抄送: qemu-devel@nongnu.org
主题: [PATCH] linux-user: fix bug about incorrect base addresss of idt and gdt on
i386 and x86_64
From 4601a624f40b2c89e7df2dec1adffb4f4308ba2d Mon Sep 17 00:00:00 2001
From: fanwenjie
Date: Sun, 1 Jan 2023 23:13:34 +0800
Subject: [PATCH] linux-user: fix bug about incorrect base addresss of idt and
gdt on i386 and x86_64
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1405
Signed-off-by: fanwenjie
---
linux-user/main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/linux-user/main.c b/linux-user/main.c
index a17fed045b..5d673c95b3 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -171,6 +171,12 @@ void fork_end(int child)
__thread CPUState *thread_cpu;
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+#include
+__thread alignas(TARGET_PAGE_SIZE) static uint64_t
gdt_base[TARGET_GDT_ENTRIES];
+__thread alignas(TARGET_PAGE_SIZE) static uint64_t idt_base[TARGET_PAGE_SIZE /
sizeof(uint64_t)];
+#endif
+
bool qemu_cpu_is_self(CPUState *cpu)
{
return thread_cpu == cpu;
@@ -235,6 +241,13 @@ CPUArchState *cpu_copy(CPUArchState *env)
new_cpu->tcg_cflags = cpu->tcg_cflags;
memcpy(new_env, env, sizeof(CPUArchState));
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+memcpy(idt_base, (void*)new_env->idt.base, sizeof(uint64_t) *
(new_env->idt.limit + 1));
+memcpy(gdt_base, (void*)new_env->gdt.base, sizeof(uint64_t) *
TARGET_GDT_ENTRIES);
+new_env->idt.base = (target_ulong)idt_base;
+new_env->gdt.base = (target_ulong)gdt_base;
+#endif
+
/* Clone all break/watchpoints.
Note: Once we support ptrace with hw-debug register access, make sure
BP_CPU break/watchpoints are handled correctly on clone. */
--
2.34.1
[PATCH] linux-user: fix bug about incorrect base addresss of idt and gdt on i386 and x86_64
From 4601a624f40b2c89e7df2dec1adffb4f4308ba2d Mon Sep 17 00:00:00 2001
From: fanwenjie
Date: Sun, 1 Jan 2023 23:13:34 +0800
Subject: [PATCH] linux-user: fix bug about incorrect base addresss of idt and
gdt on i386 and x86_64
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1405
Signed-off-by: fanwenjie
---
linux-user/main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/linux-user/main.c b/linux-user/main.c
index a17fed045b..5d673c95b3 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -171,6 +171,12 @@ void fork_end(int child)
__thread CPUState *thread_cpu;
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+#include
+__thread alignas(TARGET_PAGE_SIZE) static uint64_t
gdt_base[TARGET_GDT_ENTRIES];
+__thread alignas(TARGET_PAGE_SIZE) static uint64_t idt_base[TARGET_PAGE_SIZE /
sizeof(uint64_t)];
+#endif
+
bool qemu_cpu_is_self(CPUState *cpu)
{
return thread_cpu == cpu;
@@ -235,6 +241,13 @@ CPUArchState *cpu_copy(CPUArchState *env)
new_cpu->tcg_cflags = cpu->tcg_cflags;
memcpy(new_env, env, sizeof(CPUArchState));
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+memcpy(idt_base, (void*)new_env->idt.base, sizeof(uint64_t) *
(new_env->idt.limit + 1));
+memcpy(gdt_base, (void*)new_env->gdt.base, sizeof(uint64_t) *
TARGET_GDT_ENTRIES);
+new_env->idt.base = (target_ulong)idt_base;
+new_env->gdt.base = (target_ulong)gdt_base;
+#endif
+
/* Clone all break/watchpoints.
Note: Once we support ptrace with hw-debug register access, make sure
BP_CPU break/watchpoints are handled correctly on clone. */
--
2.34.1
[PATCH 3/4] target/m68k: fix FPSR quotient byte for fmod instruction
The FPSR quotient byte should be set to the value of the quotient and not the
result. Switch from using floatx80_mod() to floatx80_modrem() which returns
the quotient as a uint64_t which can be used for the quotient byte.
Signed-off-by: Mark Cave-Ayland
---
target/m68k/fpu_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index ae839785fa..18594a35af 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -523,14 +523,17 @@ static void make_quotient(CPUM68KState *env, int sign,
uint32_t quotient)
void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
{
-res->d = floatx80_mod(val1->d, val0->d, >fp_status);
+uint64_t quotient;
+int sign = extractFloatx80Sign(val1->d) ^ extractFloatx80Sign(val0->d);
+
+res->d = floatx80_modrem(val1->d, val0->d, true, ,
+ >fp_status);
if (floatx80_is_any_nan(res->d)) {
return;
}
-make_quotient(env, extractFloatx80Sign(res->d),
- floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, sign, quotient);
}
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
--
2.30.2
[PATCH 2/4] target/m68k: pass sign directly into make_quotient()
This enables the quotient parameter to be changed from int32_t to uint32_t and
also allows the extra sign logic in make_quotient() to be removed.
Signed-off-by: Mark Cave-Ayland
---
target/m68k/fpu_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index 0932c464fd..ae839785fa 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -515,15 +515,8 @@ uint32_t HELPER(fmovemd_ld_postinc)(CPUM68KState *env,
uint32_t addr,
return fmovem_postinc(env, addr, mask, cpu_ld_float64_ra);
}
-static void make_quotient(CPUM68KState *env, int32_t quotient)
+static void make_quotient(CPUM68KState *env, int sign, uint32_t quotient)
{
-int sign;
-
-sign = quotient < 0;
-if (sign) {
-quotient = -quotient;
-}
-
quotient = (sign << 7) | (quotient & 0x7f);
env->fpsr = (env->fpsr & ~FPSR_QT_MASK) | (quotient << FPSR_QT_SHIFT);
}
@@ -536,7 +529,8 @@ void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
return;
}
-make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
@@ -547,7 +541,8 @@ void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
return;
}
-make_quotient(env, floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, extractFloatx80Sign(res->d),
+ floatx80_to_int32(res->d, >fp_status));
}
void HELPER(fgetexp)(CPUM68KState *env, FPReg *res, FPReg *val)
--
2.30.2
[PATCH 4/4] target/m68k: fix FPSR quotient byte for frem instruction
The FPSR quotient byte should be set to the value of the quotient and not the
result. Manually calculate the quotient in the frem helper in round to nearest
even mode (note this is different from the quotient calculated internally for
fmod), and use it to set the quotient byte accordingly.
Signed-off-by: Mark Cave-Ayland
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1314
---
target/m68k/fpu_helper.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index 18594a35af..ce6f2cd2b9 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -538,14 +538,23 @@ void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
{
+FPReg fp_quot;
+float_status fp_status;
+
+/* Calculate quotient directly using round to nearest mode */
+set_float_rounding_mode(float_round_nearest_even, _status);
+set_floatx80_rounding_precision(
+get_floatx80_rounding_precision(>fp_status), _status);
+fp_quot.d = floatx80_div(val1->d, val0->d, _status);
+
res->d = floatx80_rem(val1->d, val0->d, >fp_status);
-if (floatx80_is_any_nan(res->d)) {
+if (floatx80_is_any_nan(fp_quot.d)) {
return;
}
-make_quotient(env, extractFloatx80Sign(res->d),
- floatx80_to_int32(res->d, >fp_status));
+make_quotient(env, extractFloatx80Sign(fp_quot.d),
+ abs(floatx80_to_int32(fp_quot.d, >fp_status)));
}
void HELPER(fgetexp)(CPUM68KState *env, FPReg *res, FPReg *val)
--
2.30.2
[PATCH 0/4] target/m68k: fix FPSR quotient byte for fmod and frem
This series is taken from my MacOS branch and fixes setting the FPSR quotient byte for the fmod and frem instructions which was causing the MacOS _Pack5 SANE trancendentals implementation to return incorrect values for sin() and cos(). The first 2 patches update make_quotient() to take separate sign and value parameters so that it can be used for both floatx80_modrem() and a manual division calculation, whilst the last 2 patches fix the value of the quotient byte for both the fmod and frem instructions. This series has been validated against the fmod and frem results using a custom test program which has been run on a real 68040 Mac. Many thanks to the mac68k folk for their help debugging this, in particular SolraBizna for narrowing down the issue to the transcendentals and writing the custom test program, and also treellama and Cat7 for running the test program on real hardware and uploading the generated results file for further analysis. Signed-off-by: Mark Cave-Ayland Mark Cave-Ayland (4): target/m68k: pass quotient directly into make_quotient() target/m68k: pass sign directly into make_quotient() target/m68k: fix FPSR quotient byte for fmod instruction target/m68k: fix FPSR quotient byte for frem instruction target/m68k/fpu_helper.c | 43 1 file changed, 26 insertions(+), 17 deletions(-) -- 2.30.2
[PATCH 1/4] target/m68k: pass quotient directly into make_quotient()
Signed-off-by: Mark Cave-Ayland
---
target/m68k/fpu_helper.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index fdc4937e29..0932c464fd 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -515,16 +515,10 @@ uint32_t HELPER(fmovemd_ld_postinc)(CPUM68KState *env,
uint32_t addr,
return fmovem_postinc(env, addr, mask, cpu_ld_float64_ra);
}
-static void make_quotient(CPUM68KState *env, floatx80 val)
+static void make_quotient(CPUM68KState *env, int32_t quotient)
{
-int32_t quotient;
int sign;
-if (floatx80_is_any_nan(val)) {
-return;
-}
-
-quotient = floatx80_to_int32(val, >fp_status);
sign = quotient < 0;
if (sign) {
quotient = -quotient;
@@ -538,14 +532,22 @@ void HELPER(fmod)(CPUM68KState *env, FPReg *res, FPReg
*val0, FPReg *val1)
{
res->d = floatx80_mod(val1->d, val0->d, >fp_status);
-make_quotient(env, res->d);
+if (floatx80_is_any_nan(res->d)) {
+return;
+}
+
+make_quotient(env, floatx80_to_int32(res->d, >fp_status));
}
void HELPER(frem)(CPUM68KState *env, FPReg *res, FPReg *val0, FPReg *val1)
{
res->d = floatx80_rem(val1->d, val0->d, >fp_status);
-make_quotient(env, res->d);
+if (floatx80_is_any_nan(res->d)) {
+return;
+}
+
+make_quotient(env, floatx80_to_int32(res->d, >fp_status));
}
void HELPER(fgetexp)(CPUM68KState *env, FPReg *res, FPReg *val)
--
2.30.2
[PATCH] linux-user: add more netlink protocol constants
Currently, qemu strace only prints four protocol contants. This patch
adds others listed in "linux/netlink.h".
Signed-off-by: Letu Ren
---
I found this issue when running networkmanager using qemu-user.
`socket(PF_NETLINK,SOCK_RAW,16) = -1 errno=93 (Protocol not supported)`
I don't know whether this protocol can be implemented. However, a better
log is much easier.
linux-user/strace.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/linux-user/strace.c b/linux-user/strace.c
index 9ae5a812cd..a2b2aa7248 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -506,21 +506,69 @@ print_socket_protocol(int domain, int type, int protocol)
case NETLINK_ROUTE:
qemu_log("NETLINK_ROUTE");
break;
+case NETLINK_UNUSED:
+qemu_log("NETLINK_UNUSED");
+break;
+case NETLINK_USERSOCK:
+qemu_log("NETLINK_USERSOCK");
+break;
+case NETLINK_FIREWALL:
+qemu_log("NETLINK_FIREWALL");
+break;
+case NETLINK_SOCK_DIAG:
+qemu_log("NETLINK_SOCK_DIAG");
+break;
+case NETLINK_NFLOG:
+qemu_log("NETLINK_NFLOG");
+break;
+case NETLINK_XFRM:
+qemu_log("NETLINK_XFRM");
+break;
+case NETLINK_SELINUX:
+qemu_log("NETLINK_SELINUX");
+break;
+case NETLINK_ISCSI:
+qemu_log("NETLINK_ISCSI");
+break;
case NETLINK_AUDIT:
qemu_log("NETLINK_AUDIT");
break;
+case NETLINK_FIB_LOOKUP:
+qemu_log("NETLINK_FIB_LOOKUP");
+break;
+case NETLINK_CONNECTOR:
+qemu_log("NETLINK_CONNECTOR");
+break;
case NETLINK_NETFILTER:
qemu_log("NETLINK_NETFILTER");
break;
+case NETLINK_IP6_FW:
+qemu_log("NETLINK_IP6_FW");
+break;
+case NETLINK_DNRTMSG:
+qemu_log("NETLINK_DNRTMSG");
+break;
case NETLINK_KOBJECT_UEVENT:
qemu_log("NETLINK_KOBJECT_UEVENT");
break;
+case NETLINK_GENERIC:
+qemu_log("NETLINK_GENERIC");
+break;
+case NETLINK_SCSITRANSPORT:
+qemu_log("NETLINK_SCSITRANSPORT");
+break;
+case NETLINK_ECRYPTFS:
+qemu_log("NETLINK_ECRYPTFS");
+break;
case NETLINK_RDMA:
qemu_log("NETLINK_RDMA");
break;
case NETLINK_CRYPTO:
qemu_log("NETLINK_CRYPTO");
break;
+case NETLINK_SMC:
+qemu_log("NETLINK_SMC");
+break;
default:
qemu_log("%d", protocol);
break;
--
2.39.0
Re: [PATCH qemu] x86: don't let decompressed kernel image clobber setup_data
On 1.1.2023 6.33, H. Peter Anvin wrote: On 12/31/22 10:22, Jason A. Donenfeld wrote: On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote: On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote: That failure is unrelated to the ident mapping issue Peter and I discussed. The original failure is described in the commit message: decompression clobbers the data, so sd->next points to garbage. Right So with that understanding confirmed, I'm confused at your surprise that hpa's unrelated fix to the different issue didn't fix this issue. If decompression does clobber the data, then we *also* need to figure out why that is. There are basically three possibilities: 1. If physical KASLR is NOT used: a. The boot loader doesn't honor the kernel safe area properly; b. Somewhere in the process a bug in the calculation of the kernel safe area has crept in. 2. If physical KASLR IS used: The decompressor doesn't correctly keep track of nor relocate all the keep-out zones before picking a target address. Seems setup_data is not included in those mem_avoid regions. One is a bootloader bug, two is a kernel bug. My guess is (2) is the culprit, but (1b) should be checked, too. -hpa --Mika
Re: [PATCH v3] xio3130_upstream: Add ACS (Access Control Services) capability
The upstream and downstream of the physical machine also have acs capability.
The virtual machine should at least have a way to see the acs
On Sun, Jan 1, 2023 at 5:03 PM Paul Schlacter wrote:
>
> Please help review and merge the code into the master. Thank you very much.
>
> ping
>
> On Sat, Aug 20, 2022 at 7:31 AM Paul Schlacter wrote:
> >
> > ping
> >
> > On Thu, Aug 18, 2022 at 10:25 PM Paul Schlacter wrote:
> > >
> > > If it is a pcie device, check that all devices on the path from
> > > the device to the root complex have ACS enabled, and then the
> > > device will become an iommu_group.
> > >
> > > pci_acs_path_enabled, this function in the Linux kernel, it means
> > > that if the device is a PCIe device, check the path from the
> > > device to the root complex. If ACS is all enabled, the device will
> > > become an iommu_group.
> > >
> > > acs determine whether it is a separate iommu_group.
> > >
> > > Signed-off-by: wlfightup
> > > —
> > > v3:
> > > - Suggested by Michael S. Tsirkin, use x-disable-acs, and set the
> > > default value to true, Compatible with previous defaults
> > >
> > > v2:
> > > - Allow ACS to be disabled.
> > > - Suggested by Michael S. Tsirkin, use disable-acs to set property.
> > >
> > > hw/pci-bridge/xio3130_upstream.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/hw/pci-bridge/xio3130_upstream.c
> > > b/hw/pci-bridge/xio3130_upstream.c
> > > index 5ff46ef050..f918113d76 100644
> > > --- a/hw/pci-bridge/xio3130_upstream.c
> > > +++ b/hw/pci-bridge/xio3130_upstream.c
> > > @@ -24,6 +24,7 @@
> > > #include "hw/pci/msi.h"
> > > #include "hw/pci/pcie.h"
> > > #include "hw/pci/pcie_port.h"
> > > +#include "hw/qdev-properties.h"
> > > #include "migration/vmstate.h"
> > > #include "qemu/module.h"
> > >
> > > @@ -37,6 +38,8 @@
> > > #define XIO3130_SSVID_SSID 0
> > > #define XIO3130_EXP_OFFSET 0x90
> > > #define XIO3130_AER_OFFSET 0x100
> > > +#define XIO3130_ACS_OFFSET \
> > > +(XIO3130_AER_OFFSET + PCI_ERR_SIZEOF)
> > >
> > > static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address,
> > > uint32_t val, int len)
> > > @@ -57,6 +60,7 @@ static void xio3130_upstream_reset(DeviceState *qdev)
> > > static void xio3130_upstream_realize(PCIDevice *d, Error **errp)
> > > {
> > > PCIEPort *p = PCIE_PORT(d);
> > > +PCIESlot *s = PCIE_SLOT(d);
> > > int rc;
> > >
> > > pci_bridge_initfn(d, TYPE_PCIE_BUS);
> > > @@ -92,6 +96,9 @@ static void xio3130_upstream_realize(PCIDevice *d,
> > > Error **errp)
> > > goto err;
> > > }
> > >
> > > +if (!s->disable_acs) {
> > > +pcie_acs_init(d, XIO3130_ACS_OFFSET);
> > > +}
> > > return;
> > >
> > > err:
> > > @@ -110,6 +117,11 @@ static void xio3130_upstream_exitfn(PCIDevice *d)
> > > pci_bridge_exitfn(d);
> > > }
> > >
> > > +static Property xio3130_upstream_props[] = {
> > > +DEFINE_PROP_BOOL("x-disable-acs", PCIESlot, disable_acs, true),
> > > +DEFINE_PROP_END_OF_LIST()
> > > +};
> > > +
> > > static const VMStateDescription vmstate_xio3130_upstream = {
> > > .name = "xio3130-express-upstream-port",
> > > .priority = MIG_PRI_PCI_BUS,
> > > @@ -139,6 +151,7 @@ static void xio3130_upstream_class_init(ObjectClass
> > > *klass, void *data)
> > > dc->desc = "TI X3130 Upstream Port of PCI Express Switch";
> > > dc->reset = xio3130_upstream_reset;
> > > dc->vmsd = _xio3130_upstream;
> > > +device_class_set_props(dc, xio3130_upstream_props);
> > > }
> > >
> > > static const TypeInfo xio3130_upstream_info = {
> > > --
> > > 2.24.3 (Apple Git-128)
> > >
> > >
Re: [PATCH v3] xio3130_upstream: Add ACS (Access Control Services) capability
Please help review and merge the code into the master. Thank you very much.
ping
On Sat, Aug 20, 2022 at 7:31 AM Paul Schlacter wrote:
>
> ping
>
> On Thu, Aug 18, 2022 at 10:25 PM Paul Schlacter wrote:
> >
> > If it is a pcie device, check that all devices on the path from
> > the device to the root complex have ACS enabled, and then the
> > device will become an iommu_group.
> >
> > pci_acs_path_enabled, this function in the Linux kernel, it means
> > that if the device is a PCIe device, check the path from the
> > device to the root complex. If ACS is all enabled, the device will
> > become an iommu_group.
> >
> > acs determine whether it is a separate iommu_group.
> >
> > Signed-off-by: wlfightup
> > —
> > v3:
> > - Suggested by Michael S. Tsirkin, use x-disable-acs, and set the
> > default value to true, Compatible with previous defaults
> >
> > v2:
> > - Allow ACS to be disabled.
> > - Suggested by Michael S. Tsirkin, use disable-acs to set property.
> >
> > hw/pci-bridge/xio3130_upstream.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/hw/pci-bridge/xio3130_upstream.c
> > b/hw/pci-bridge/xio3130_upstream.c
> > index 5ff46ef050..f918113d76 100644
> > --- a/hw/pci-bridge/xio3130_upstream.c
> > +++ b/hw/pci-bridge/xio3130_upstream.c
> > @@ -24,6 +24,7 @@
> > #include "hw/pci/msi.h"
> > #include "hw/pci/pcie.h"
> > #include "hw/pci/pcie_port.h"
> > +#include "hw/qdev-properties.h"
> > #include "migration/vmstate.h"
> > #include "qemu/module.h"
> >
> > @@ -37,6 +38,8 @@
> > #define XIO3130_SSVID_SSID 0
> > #define XIO3130_EXP_OFFSET 0x90
> > #define XIO3130_AER_OFFSET 0x100
> > +#define XIO3130_ACS_OFFSET \
> > +(XIO3130_AER_OFFSET + PCI_ERR_SIZEOF)
> >
> > static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address,
> > uint32_t val, int len)
> > @@ -57,6 +60,7 @@ static void xio3130_upstream_reset(DeviceState *qdev)
> > static void xio3130_upstream_realize(PCIDevice *d, Error **errp)
> > {
> > PCIEPort *p = PCIE_PORT(d);
> > +PCIESlot *s = PCIE_SLOT(d);
> > int rc;
> >
> > pci_bridge_initfn(d, TYPE_PCIE_BUS);
> > @@ -92,6 +96,9 @@ static void xio3130_upstream_realize(PCIDevice *d, Error
> > **errp)
> > goto err;
> > }
> >
> > +if (!s->disable_acs) {
> > +pcie_acs_init(d, XIO3130_ACS_OFFSET);
> > +}
> > return;
> >
> > err:
> > @@ -110,6 +117,11 @@ static void xio3130_upstream_exitfn(PCIDevice *d)
> > pci_bridge_exitfn(d);
> > }
> >
> > +static Property xio3130_upstream_props[] = {
> > +DEFINE_PROP_BOOL("x-disable-acs", PCIESlot, disable_acs, true),
> > +DEFINE_PROP_END_OF_LIST()
> > +};
> > +
> > static const VMStateDescription vmstate_xio3130_upstream = {
> > .name = "xio3130-express-upstream-port",
> > .priority = MIG_PRI_PCI_BUS,
> > @@ -139,6 +151,7 @@ static void xio3130_upstream_class_init(ObjectClass
> > *klass, void *data)
> > dc->desc = "TI X3130 Upstream Port of PCI Express Switch";
> > dc->reset = xio3130_upstream_reset;
> > dc->vmsd = _xio3130_upstream;
> > +device_class_set_props(dc, xio3130_upstream_props);
> > }
> >
> > static const TypeInfo xio3130_upstream_info = {
> > --
> > 2.24.3 (Apple Git-128)
> >
> >
