[Bug 1851095] [NEW] [feature request] awareness of instructions that are well emulated
Public bug reported: While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64)--i have found this both for mipsel and arm32. Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed. ** Affects: qemu Importance: Undecided Status: New ** Description changed: While qemu's scalar emulation tends to be excellent, qemu's SIMD - emulation tends to be incorrect (except for arm64 from x86_64). Until - these code paths are audited, which is probably a large job, it would be - nice if qemu knew its emulation of this class of instructions was not - very good, and thus it would give up on finding these instructions if a - "careful" operation is passed. + emulation tends to be incorrect (except for arm64 from x86_64)--i have + found this both for mipsel and arm32. Until these code paths are + audited, which is probably a large job, it would be nice if qemu knew + its emulation of this class of instructions was not very good, and thus + it would give up on finding these instructions if a "careful" operation + is passed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1851095 Title: [feature request] awareness of instructions that are well emulated Status in QEMU: New Bug description: While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64)--i have found this both for mipsel and arm32. Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1851095/+subscriptions
[Bug 1851095] Re: [feature request] awareness of instructions that are well emulated
Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/ I have more code for validation if someone is working on this. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1851095 Title: [feature request] awareness of instructions that are well emulated Status in QEMU: New Bug description: While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64)--i have found this both for mipsel and arm32. Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1851095/+subscriptions
[PATCH v2] q800: fix I/O memory map
Linux kernel 5.4 will introduce a new memory map for SWIM device.
(aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base addresses"))
Until this release all MMIO are mapped between 0x50f0 and 0x50f4,
but it appears that for real hardware 0x50f0 is not the base address:
the MMIO region spans 0x5000 through 0x6000, and 0x5004 through
0x5400 is repeated images of 0x5000 to 0x5004.
Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
Signed-off-by: Laurent Vivier
---
Notes:
v2: add some constant definitions
allocate a bloc of memory to stores all I/O MemoryRegion
hw/m68k/q800.c | 40
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 2b4842f8c6..822bd13d36 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -60,14 +60,19 @@
#define MACH_MAC3
#define Q800_MAC_CPU_ID 2
-#define VIA_BASE 0x50f0
-#define SONIC_PROM_BASE 0x50f08000
-#define SONIC_BASE0x50f0a000
-#define SCC_BASE 0x50f0c020
-#define ESP_BASE 0x50f1
-#define ESP_PDMA 0x50f10100
-#define ASC_BASE 0x50F14000
-#define SWIM_BASE 0x50F1E000
+#define IO_BASE 0x5000
+#define IO_SLICE 0x0004
+#define IO_SIZE 0x0400
+
+#define VIA_BASE (IO_BASE + 0x0)
+#define SONIC_PROM_BASE (IO_BASE + 0x08000)
+#define SONIC_BASE(IO_BASE + 0x0a000)
+#define SCC_BASE (IO_BASE + 0x0c020)
+#define ESP_BASE (IO_BASE + 0x1)
+#define ESP_PDMA (IO_BASE + 0x10100)
+#define ASC_BASE (IO_BASE + 0x14000)
+#define SWIM_BASE (IO_BASE + 0x1E000)
+
#define NUBUS_SUPER_SLOT_BASE 0x6000
#define NUBUS_SLOT_BASE 0xf000
@@ -135,6 +140,9 @@ static void q800_init(MachineState *machine)
int32_t initrd_size;
MemoryRegion *rom;
MemoryRegion *ram;
+MemoryRegion *io;
+const int io_slice_nb = (IO_SIZE / IO_SLICE) - 1;
+int i;
ram_addr_t ram_size = machine->ram_size;
const char *kernel_filename = machine->kernel_filename;
const char *initrd_filename = machine->initrd_filename;
@@ -163,10 +171,26 @@ static void q800_init(MachineState *machine)
cpu = M68K_CPU(cpu_create(machine->cpu_type));
qemu_register_reset(main_cpu_reset, cpu);
+/* RAM */
ram = g_malloc(sizeof(*ram));
memory_region_init_ram(ram, NULL, "m68k_mac.ram", ram_size, &error_abort);
memory_region_add_subregion(get_system_memory(), 0, ram);
+/*
+ * Memory from IO_BASE to IO_BASE + IO_SLICE is repeated
+ * from IO_BASE + IO_SLICE to IO_BASE + IO_SIZE
+ */
+io = g_new(MemoryRegion, io_slice_nb);
+for (i = 0; i < io_slice_nb; i++) {
+char *name = g_strdup_printf("mac_m68k.io[%d]", i + 1);
+
+memory_region_init_alias(io + i, NULL, name, get_system_memory(),
+ IO_BASE, IO_SLICE);
+memory_region_add_subregion(get_system_memory(),
+IO_BASE + (i + 1) * IO_SLICE, io + i);
+g_free(name);
+}
+
/* IRQ Glue */
irq = g_new0(GLUEState, 1);
--
2.21.0
Re: [PULL 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
On 11/2/19 9:28 PM, Philippe Mathieu-Daudé wrote: Hi Paolo, On 10/30/19 10:44 AM, Philippe Mathieu-Daudé wrote: Hi Peter, Paolo, On 10/30/19 7:15 AM, Peter Maydell wrote: On Mon, 28 Oct 2019 at 17:48, Philippe Mathieu-Daudé wrote: The i440FX northbridge is only used by the PC machine, while the PIIX southbridge is also used by the Malta MIPS machine. Split the PIIX3 southbridge from i440FX northbridge. I get a link failure on my 'do a make clean and then make' build : LINK i386-softmmu/qemu-system-i386 hw/i386/pc_piix.o: In function `pc_init1': /home/petmay01/linaro/qemu-for-merges/hw/i386/pc_piix.c:197: undefined reference to `i440fx_init' /home/petmay01/linaro/qemu-for-merges/hw/i386/pc_piix.c:206: undefined reference to `piix3_create' collect2: error: ld returned 1 exit status This is odd, default-configs/i386-softmmu.mak selects CONFIG_I440FX, I440FX selects PCI_I440FX, and the Makefile.objs has: common-obj-$(CONFIG_PCI_I440FX) += i440fx.o The change is in patch "hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'" which is a simple rename: -- >8 -- diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig index d420b35548..5a494342ea 100644 --- a/hw/i386/Kconfig +++ b/hw/i386/Kconfig @@ -60,7 +60,7 @@ config I440FX select PC_PCI select PC_ACPI select ACPI_SMBUS - select PCI_PIIX + select PCI_I440FX select PIIX3 select IDE_PIIX select DIMM diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig index 397043b289..b0aa8351c4 100644 --- a/hw/pci-host/Kconfig +++ b/hw/pci-host/Kconfig @@ -28,7 +28,7 @@ config PCI_SABRE select PCI bool -config PCI_PIIX +config PCI_I440FX bool select PCI select PAM diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs index a9cd3e022d..efd752b766 100644 --- a/hw/pci-host/Makefile.objs +++ b/hw/pci-host/Makefile.objs @@ -13,7 +13,7 @@ common-obj-$(CONFIG_VERSATILE_PCI) += versatile.o common-obj-$(CONFIG_PCI_SABRE) += sabre.o common-obj-$(CONFIG_FULONG) += bonito.o -common-obj-$(CONFIG_PCI_PIIX) += piix.o +common-obj-$(CONFIG_PCI_I440FX) += i440fx.o common-obj-$(CONFIG_PCI_EXPRESS_Q35) += q35.o common-obj-$(CONFIG_PCI_EXPRESS_GENERIC_BRIDGE) += gpex.o common-obj-$(CONFIG_PCI_EXPRESS_XILINX) += xilinx-pcie.o diff --git a/hw/pci-host/piix.c b/hw/pci-host/i440fx.c similarity index 100% rename from hw/pci-host/piix.c rename to hw/pci-host/i440fx.c --- I could reproduce and hw/pci-host/ doesn't contains neither piix.o nor i440fx.o. $ fgrep -ri i440fx i386-softmmu/ i386-softmmu/config-devices.h-timestamp:#define CONFIG_I440FX 1 i386-softmmu/config-devices.mak.old:CONFIG_I440FX=y Binary file i386-softmmu/hw/i386/pc_piix.o matches i386-softmmu/hw/i386/pc_piix.d: /home/phil/source/qemu/include/hw/pci-host/i440fx.h \ i386-softmmu/hw/i386/pc_piix.d:/home/phil/source/qemu/include/hw/pci-host/i440fx.h: Binary file i386-softmmu/hw/i386/acpi-build.o matches Binary file i386-softmmu/hw/i386/pc.o matches i386-softmmu/config-devices.mak:CONFIG_I440FX=y i386-softmmu/config-devices.h:#define CONFIG_I440FX 1 So CONFIG_I440FX is here, but no CONFIG_PCI_I440FX... $ fgrep -r PIIX i386-softmmu/ i386-softmmu/config-devices.h-timestamp:#define CONFIG_IDE_PIIX 1 i386-softmmu/config-devices.h-timestamp:#define CONFIG_PCI_PIIX 1 i386-softmmu/config-devices.mak.old:CONFIG_IDE_PIIX=y i386-softmmu/config-devices.mak.old:CONFIG_PCI_PIIX=y Binary file i386-softmmu/hw/i386/pc_piix.o matches Binary file i386-softmmu/hw/i386/acpi-build.o matches Binary file i386-softmmu/hw/i386/pc.o matches i386-softmmu/config-devices.mak:CONFIG_IDE_PIIX=y i386-softmmu/config-devices.mak:CONFIG_PCI_PIIX=y i386-softmmu/config-devices.h:#define CONFIG_IDE_PIIX 1 i386-softmmu/config-devices.h:#define CONFIG_PCI_PIIX 1 And the old CONFIG_PCI_PIIX is still there :( Paolo, is some kconfig dependency missing? docs/devel/build-system.txt is misleading: - $TARGET-NAME/config-devices.mak TARGET-NAME is again the name of a system or userspace emulator. The config-devices.mak file is automatically generated by make using the scripts/make_device_config.sh program, feeding it the default-configs/$TARGET-NAME file as input. But this script has been removed in e0e312f3525: build: switch to Kconfig The make_device_config.sh script is replaced by minikconf, which is modified to support the same command line as its predecessor. Anyway, back to my problem. We modified hw/i386/Kconfig and hw/pci-host/Kconfig. i386-softmmu/config-devices.mak hasn't been rebuilt. Here is the make rule matching i386-softmmu/config-devices.mak: $(SUBDIR_DEVICES_MAK): %/config-devices.mak: default-configs/%.mak $(MINIKCONF_INPUTS) $(BUILD_DIR)/config-host.mak $(call quiet-command, $(MINIKCONF) $(MINIKCONF_ARGS) > $@.tmp, "GEN", "$@.tmp") With: MINIKCONF_INPUTS = $(SRC_PATH)
Re: [PULL 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
Hi Paolo,
On 10/30/19 10:44 AM, Philippe Mathieu-Daudé wrote:
Hi Peter, Paolo,
On 10/30/19 7:15 AM, Peter Maydell wrote:
On Mon, 28 Oct 2019 at 17:48, Philippe Mathieu-Daudé
wrote:
The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.
Split the PIIX3 southbridge from i440FX northbridge.
I get a link failure on my 'do a make clean and then make' build :
LINK i386-softmmu/qemu-system-i386
hw/i386/pc_piix.o: In function `pc_init1':
/home/petmay01/linaro/qemu-for-merges/hw/i386/pc_piix.c:197: undefined
reference to `i440fx_init'
/home/petmay01/linaro/qemu-for-merges/hw/i386/pc_piix.c:206: undefined
reference to `piix3_create'
collect2: error: ld returned 1 exit status
This is odd, default-configs/i386-softmmu.mak selects CONFIG_I440FX,
I440FX selects PCI_I440FX, and the Makefile.objs has:
common-obj-$(CONFIG_PCI_I440FX) += i440fx.o
The change is in patch "hw/pci-host: Rename incorrectly named 'piix' as
'i440fx'" which is a simple rename:
-- >8 --
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index d420b35548..5a494342ea 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -60,7 +60,7 @@ config I440FX
select PC_PCI
select PC_ACPI
select ACPI_SMBUS
- select PCI_PIIX
+ select PCI_I440FX
select PIIX3
select IDE_PIIX
select DIMM
diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index 397043b289..b0aa8351c4 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -28,7 +28,7 @@ config PCI_SABRE
select PCI
bool
-config PCI_PIIX
+config PCI_I440FX
bool
select PCI
select PAM
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index a9cd3e022d..efd752b766 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -13,7 +13,7 @@ common-obj-$(CONFIG_VERSATILE_PCI) += versatile.o
common-obj-$(CONFIG_PCI_SABRE) += sabre.o
common-obj-$(CONFIG_FULONG) += bonito.o
-common-obj-$(CONFIG_PCI_PIIX) += piix.o
+common-obj-$(CONFIG_PCI_I440FX) += i440fx.o
common-obj-$(CONFIG_PCI_EXPRESS_Q35) += q35.o
common-obj-$(CONFIG_PCI_EXPRESS_GENERIC_BRIDGE) += gpex.o
common-obj-$(CONFIG_PCI_EXPRESS_XILINX) += xilinx-pcie.o
diff --git a/hw/pci-host/piix.c b/hw/pci-host/i440fx.c
similarity index 100%
rename from hw/pci-host/piix.c
rename to hw/pci-host/i440fx.c
---
I could reproduce and hw/pci-host/ doesn't contains neither piix.o nor
i440fx.o.
$ fgrep -ri i440fx i386-softmmu/
i386-softmmu/config-devices.h-timestamp:#define CONFIG_I440FX 1
i386-softmmu/config-devices.mak.old:CONFIG_I440FX=y
Binary file i386-softmmu/hw/i386/pc_piix.o matches
i386-softmmu/hw/i386/pc_piix.d:
/home/phil/source/qemu/include/hw/pci-host/i440fx.h \
i386-softmmu/hw/i386/pc_piix.d:/home/phil/source/qemu/include/hw/pci-host/i440fx.h:
Binary file i386-softmmu/hw/i386/acpi-build.o matches
Binary file i386-softmmu/hw/i386/pc.o matches
i386-softmmu/config-devices.mak:CONFIG_I440FX=y
i386-softmmu/config-devices.h:#define CONFIG_I440FX 1
So CONFIG_I440FX is here, but no CONFIG_PCI_I440FX...
$ fgrep -r PIIX i386-softmmu/
i386-softmmu/config-devices.h-timestamp:#define CONFIG_IDE_PIIX 1
i386-softmmu/config-devices.h-timestamp:#define CONFIG_PCI_PIIX 1
i386-softmmu/config-devices.mak.old:CONFIG_IDE_PIIX=y
i386-softmmu/config-devices.mak.old:CONFIG_PCI_PIIX=y
Binary file i386-softmmu/hw/i386/pc_piix.o matches
Binary file i386-softmmu/hw/i386/acpi-build.o matches
Binary file i386-softmmu/hw/i386/pc.o matches
i386-softmmu/config-devices.mak:CONFIG_IDE_PIIX=y
i386-softmmu/config-devices.mak:CONFIG_PCI_PIIX=y
i386-softmmu/config-devices.h:#define CONFIG_IDE_PIIX 1
i386-softmmu/config-devices.h:#define CONFIG_PCI_PIIX 1
And the old CONFIG_PCI_PIIX is still there :(
Paolo, is some kconfig dependency missing?
docs/devel/build-system.txt is misleading:
- $TARGET-NAME/config-devices.mak
TARGET-NAME is again the name of a system or userspace emulator. The
config-devices.mak file is automatically generated by make using the
scripts/make_device_config.sh program, feeding it the
default-configs/$TARGET-NAME file as input.
But this script has been removed in e0e312f3525:
build: switch to Kconfig
The make_device_config.sh script is replaced by minikconf, which
is modified to support the same command line as its predecessor.
Anyway, back to my problem. We modified hw/i386/Kconfig and
hw/pci-host/Kconfig. i386-softmmu/config-devices.mak hasn't been rebuilt.
Here is the make rule matching i386-softmmu/config-devices.mak:
$(SUBDIR_DEVICES_MAK): %/config-devices.mak: default-configs/%.mak
$(MINIKCONF_INPUTS) $(BUILD_DIR)/config-host.mak
$(call quiet-command, $(MINIKCONF) $(MINIKCONF_ARGS) > $@.tmp, "GEN",
"$@.tmp")
With:
MINIKCONF_INPUTS = $(SRC_PATH)/Kconfig.host $(SRC_PATH)/hw/Kconfig
So hw/{i386,pci-host}/Kco
Re: [PATCH 2/3] dp8393x: fix dp8393x_receive()
Le 02/11/2019 à 20:41, Philippe Mathieu-Daudé a écrit :
> On 11/2/19 6:15 PM, Laurent Vivier wrote:
>> address_space_rw() access size must be multiplied by the width.
>>
>> This fixes DHCP for Q800 guest.
>>
>> Signed-off-by: Laurent Vivier
>> ---
>> hw/net/dp8393x.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
>> index 85d3f3788e..b8c4473f99 100644
>> --- a/hw/net/dp8393x.c
>> +++ b/hw/net/dp8393x.c
>> @@ -833,7 +833,7 @@ static ssize_t dp8393x_receive(NetClientState *nc,
>> const uint8_t * buf,
>> } else {
>> dp8393x_put(s, width, 0, 0); /* in_use */
>> address_space_rw(&s->as, dp8393x_crda(s) + sizeof(uint16_t)
>> * 6 * width,
>> - MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data,
>> sizeof(uint16_t), 1);
>> + MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 1);
>
> Which is following:
>
> if (s->regs[SONIC_LLFA] & 0x1) {
> size = sizeof(uint16_t) * 1 * width;
but we have "size = sizeof(uint16_t) * width;" later.
This file needs cleanup...
> So OK (you describe 'width' but use 'size').
>
I meant the access size "sizeof(uint16_t)" must be adjusted by the width
of the bus (defined by (s->regs[SONIC_DCR] & SONIC_DCR_DW). [1]
And this is exactly what contains "size".
> Reviewed-by: Philippe Mathieu-Daudé
>
Thanks,
Laurent
[1] DP83932C-20/25/33 MHz SONIC (tm) Systems-Oriented Network Interface
Controller
"1.3 DATA WIDTH AND BYTE ORDERING
The SONIC can be programmed to operate with either
32-bit or 16-bit wide memory. The data width is configured
during initialization by programming the DW bit in the Data
Configuration Register (DCR, Section 4.3.2). If the 16-bit
data path is selected, data is driven on pins D15– D0."
Re: Sparc Solaris 10
Cc'ing the SPARC maintainers. On 11/1/19 4:49 AM, Zainuddin AR wrote: Hi, I like to find to find out if you have a working qemu on solaris 10 or 11. I have tried the qemu-sun4vniagara but without networking. Is the networking support for niagara version available? Regards Zai
Re: [RFC] q800: fix I/O memory map
Le 02/11/2019 à 20:54, Philippe Mathieu-Daudé a écrit : > On 11/2/19 7:10 PM, Laurent Vivier wrote: >> Paolo, >> >> the RFC was mainly for you: >> >> Is this the good way to replicate 256 times a memory chunk containing a >> bunch of different MMIO spaces? > > I asked Richard about this and he said this is OK because this is > the FlatView memory tree. It is then optimized in AddressSpace > (see memory_region_transaction_commit). What matters in term of > performance are the AddressSpaces. Thank you Philippe. Laurent
Re: [RFC] q800: fix I/O memory map
On 11/2/19 7:10 PM, Laurent Vivier wrote:
Paolo,
the RFC was mainly for you:
Is this the good way to replicate 256 times a memory chunk containing a
bunch of different MMIO spaces?
I asked Richard about this and he said this is OK because this is
the FlatView memory tree. It is then optimized in AddressSpace
(see memory_region_transaction_commit). What matters in term of
performance are the AddressSpaces.
...
+/*
+ * Memory from VIA_BASE to VIA_BASE + 0x4 is repeated
+ * from VIA_BASE + 0x4 to VIA_BASE + 0x400
+ */
+for (i = 1; i < 256; i++) {
+MemoryRegion *io = g_malloc(sizeof(*io));
+char *name = g_strdup_printf("mac_m68k.io[%d]", i);
+
+memory_region_init_alias(io, NULL, name, get_system_memory(),
+ VIA_BASE, 0x4);
+memory_region_add_subregion(get_system_memory(),
+VIA_BASE + i * 0x4, io);
+g_free(name);
+}
+
...
Thanks,
Laurent
Re: [PATCH 2/3] dp8393x: fix dp8393x_receive()
On 11/2/19 6:15 PM, Laurent Vivier wrote:
address_space_rw() access size must be multiplied by the width.
This fixes DHCP for Q800 guest.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 85d3f3788e..b8c4473f99 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -833,7 +833,7 @@ static ssize_t dp8393x_receive(NetClientState *nc, const
uint8_t * buf,
} else {
dp8393x_put(s, width, 0, 0); /* in_use */
address_space_rw(&s->as, dp8393x_crda(s) + sizeof(uint16_t) * 6 *
width,
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, sizeof(uint16_t), 1);
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 1);
Which is following:
if (s->regs[SONIC_LLFA] & 0x1) {
size = sizeof(uint16_t) * 1 * width;
So OK (you describe 'width' but use 'size').
Reviewed-by: Philippe Mathieu-Daudé
s->regs[SONIC_CRDA] = s->regs[SONIC_LLFA];
s->regs[SONIC_ISR] |= SONIC_ISR_PKTRX;
s->regs[SONIC_RSC] = (s->regs[SONIC_RSC] & 0xff00) | (((s->regs[SONIC_RSC]
& 0x00ff) + 1) & 0x00ff);
Re: [PULL] Update my MAINTAINERS file entry
On Fri, 1 Nov 2019 at 16:17, Palmer Dabbelt wrote: > > The following changes since commit b7c9a7f353c0e260519bf735ff0d4aa01e72784b: > > Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into > staging (2019-10-31 15:57:30 +) > > are available in the Git repository at: > > git://github.com/palmer-dabbelt/qemu.git tags/palmer-for-master-4.2-sf1 > > for you to fetch changes up to c1677bcc395eb977cc7279a1af0a1d23ad23fdd4: > > MAINTAINERS: Change to my personal email address (2019-11-01 09:13:30 -0700) > > > Update my MAINTAINERS file entry > > This contains a single patch to change my email address. > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2 for any user-visible changes. -- PMM
Re: [RFC] q800: fix I/O memory map
Paolo,
the RFC was mainly for you:
Is this the good way to replicate 256 times a memory chunk containing a
bunch of different MMIO spaces?
...
> +/*
> + * Memory from VIA_BASE to VIA_BASE + 0x4 is repeated
> + * from VIA_BASE + 0x4 to VIA_BASE + 0x400
> + */
> +for (i = 1; i < 256; i++) {
> +MemoryRegion *io = g_malloc(sizeof(*io));
> +char *name = g_strdup_printf("mac_m68k.io[%d]", i);
> +
> +memory_region_init_alias(io, NULL, name, get_system_memory(),
> + VIA_BASE, 0x4);
> +memory_region_add_subregion(get_system_memory(),
> +VIA_BASE + i * 0x4, io);
> +g_free(name);
> +}
> +
...
Thanks,
Laurent
Re: [RFC] q800: fix I/O memory map
Le 01/11/2019 à 01:00, Philippe Mathieu-Daudé a écrit :
> On 10/31/19 11:03 AM, Laurent Vivier wrote:
>> Linux kernel 5.4 will introduce a new memory map for SWIM device.
>> (aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base
>> addresses"))
>>
>> Until this release all MMIO are mapped between 0x50f0 and 0x50f4,
>> but it appears that for real hardware 0x50f0 is not the base address:
>> the MMIO region spans 0x5000 through 0x6000, and 0x5004
>> through
>> 0x5400 is repeated images of 0x5000 to 0x5004.
>>
>> Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
>> Signed-off-by: Laurent Vivier
>> ---
>> hw/m68k/q800.c | 33 +
>> 1 file changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
>> index 2b4842f8c6..8122e7c612 100644
>> --- a/hw/m68k/q800.c
>> +++ b/hw/m68k/q800.c
>> @@ -60,14 +60,14 @@
>> #define MACH_MAC 3
>> #define Q800_MAC_CPU_ID 2
>> -#define VIA_BASE 0x50f0
>> -#define SONIC_PROM_BASE 0x50f08000
>> -#define SONIC_BASE 0x50f0a000
>> -#define SCC_BASE 0x50f0c020
>> -#define ESP_BASE 0x50f1
>> -#define ESP_PDMA 0x50f10100
>> -#define ASC_BASE 0x50F14000
>> -#define SWIM_BASE 0x50F1E000
>> +#define VIA_BASE 0x5000
>> +#define SONIC_PROM_BASE 0x50008000
>> +#define SONIC_BASE 0x5000a000
>> +#define SCC_BASE 0x5000c020
>> +#define ESP_BASE 0x5001
>> +#define ESP_PDMA 0x50010100
>> +#define ASC_BASE 0x50014000
>> +#define SWIM_BASE 0x5001E000
>> #define NUBUS_SUPER_SLOT_BASE 0x6000
>> #define NUBUS_SLOT_BASE 0xf000
>> @@ -135,6 +135,7 @@ static void q800_init(MachineState *machine)
>> int32_t initrd_size;
>> MemoryRegion *rom;
>> MemoryRegion *ram;
>> + int i;
>> ram_addr_t ram_size = machine->ram_size;
>> const char *kernel_filename = machine->kernel_filename;
>> const char *initrd_filename = machine->initrd_filename;
>> @@ -163,10 +164,26 @@ static void q800_init(MachineState *machine)
>> cpu = M68K_CPU(cpu_create(machine->cpu_type));
>> qemu_register_reset(main_cpu_reset, cpu);
>> + /* RAM */
>> ram = g_malloc(sizeof(*ram));
>> memory_region_init_ram(ram, NULL, "m68k_mac.ram", ram_size,
>> &error_abort);
>> memory_region_add_subregion(get_system_memory(), 0, ram);
>> + /*
>> + * Memory from VIA_BASE to VIA_BASE + 0x4 is repeated
>> + * from VIA_BASE + 0x4 to VIA_BASE + 0x400
>> + */
>
> Maybe:
>
> const size_t via_aliases_count = (0x400 / 0x4) - 1;
good idea.
> MemoryRegion *via_alias = g_new(MemoryRegion, via_aliases_count);
do we really need to store them?
We will not reuse them or free them.
> for (size_t i = 0; i < via_aliases_count; i++) {
>
> ...
>
> memory_region_add_subregion(get_system_memory(),
> VIA_BASE + (i + 1) * 0x4,
> via_alias[i]);
> ...
> }
>
>> + for (i = 1; i < 256; i++) {
>> + MemoryRegion *io = g_malloc(sizeof(*io));
>> + char *name = g_strdup_printf("mac_m68k.io[%d]", i);
>> +
>> + memory_region_init_alias(io, NULL, name, get_system_memory(),
>> + VIA_BASE, 0x4);
>> + memory_region_add_subregion(get_system_memory(),
>> + VIA_BASE + i * 0x4, io);
>> + g_free(name);
>> + }
>
> I'm trying to get ride of this pattern, so I plan to refactor this later
> (and will use 256*KiB). Anyway not this patch problem.
>
> Reviewed-by: Philippe Mathieu-Daudé
>
>> +
>> /* IRQ Glue */
>> irq = g_new0(GLUEState, 1);
>>
Thanks,
Laurent
Re: [PULL 00/11] target-arm queue
On Fri, 1 Nov 2019 at 14:25, Andrew Jones wrote: > > On Fri, Nov 01, 2019 at 12:53:42PM +, Peter Maydell wrote: > > On Fri, 1 Nov 2019 at 10:34, Peter Maydell wrote: > > > > > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones wrote: > > > > Darn it. Sorry about that, but if it's still failing then I think QEMU > > > > must believe KVM is enabled, i.e. kvm_enabled() in QEMU must be true. > > > > I can try to confirm that and fix it, but I'll need to set up this > > > > environment first. > > > > > > Yeah, it looks like trying to run with KVM in an aarch32 chroot > > > doesn't work but we don't notice it -- in qemu kvm_init() succeeds > > > but then we fail when we try to actually create CPUs, so: > > > $ ./arm-softmmu/qemu-system-arm -M virt -M accel=kvm:tcg > > > qemu-system-arm: kvm_init_vcpu failed: Invalid argument > > > > > > we barf rather than falling back to tcg the way we ought to. > > > > I spoke to Christoffer and Marc about this, and they reckoned > > this was basically a kernel bug (and ideally a 64-bit kernel > > should just refuse to open /dev/kvm for an aarch32-compat > > userspace process, because it doesn't provide the aarch32 KVM > > interface, only the aarch64 one). > > > > In the meantime, we should just bodge whatever we need to > > in this test to cause us not to bother to try to run the test, > > in whatever is the most expedient way. > > How about just doing this (which can be cleanly applied to 2/9 > without conflicts on rebase) Yep, that works. I squashed it in and have applied the updated pullreq. thanks -- PMM
[PATCH 2/3] dp8393x: fix dp8393x_receive()
address_space_rw() access size must be multiplied by the width.
This fixes DHCP for Q800 guest.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 85d3f3788e..b8c4473f99 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -833,7 +833,7 @@ static ssize_t dp8393x_receive(NetClientState *nc, const
uint8_t * buf,
} else {
dp8393x_put(s, width, 0, 0); /* in_use */
address_space_rw(&s->as, dp8393x_crda(s) + sizeof(uint16_t) * 6 *
width,
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, sizeof(uint16_t), 1);
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 1);
s->regs[SONIC_CRDA] = s->regs[SONIC_LLFA];
s->regs[SONIC_ISR] |= SONIC_ISR_PKTRX;
s->regs[SONIC_RSC] = (s->regs[SONIC_RSC] & 0xff00) |
(((s->regs[SONIC_RSC] & 0x00ff) + 1) & 0x00ff);
--
2.21.0
[PATCH 1/3] dp8393x: put the DMA buffer in the state structure
Move it from the stack.
It's only 24 bytes, and this simplifies the dp8393x_get()/
dp8393x_put() interface.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 105 ++-
1 file changed, 50 insertions(+), 55 deletions(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 693e244ce6..85d3f3788e 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -171,6 +171,7 @@ typedef struct dp8393xState {
/* Temporaries */
uint8_t tx_buffer[0x1];
+uint16_t data[12];
int loopback_packet;
/* Memory access */
@@ -224,26 +225,25 @@ static uint32_t dp8393x_wt(dp8393xState *s)
return s->regs[SONIC_WT1] << 16 | s->regs[SONIC_WT0];
}
-static uint16_t dp8393x_get(dp8393xState *s, int width, uint16_t *base,
-int offset)
+static uint16_t dp8393x_get(dp8393xState *s, int width, int offset)
{
uint16_t val;
if (s->big_endian) {
-val = be16_to_cpu(base[offset * width + width - 1]);
+val = be16_to_cpu(s->data[offset * width + width - 1]);
} else {
-val = le16_to_cpu(base[offset * width]);
+val = le16_to_cpu(s->data[offset * width]);
}
return val;
}
-static void dp8393x_put(dp8393xState *s, int width, uint16_t *base, int offset,
+static void dp8393x_put(dp8393xState *s, int width, int offset,
uint16_t val)
{
if (s->big_endian) {
-base[offset * width + width - 1] = cpu_to_be16(val);
+s->data[offset * width + width - 1] = cpu_to_be16(val);
} else {
-base[offset * width] = cpu_to_le16(val);
+s->data[offset * width] = cpu_to_le16(val);
}
}
@@ -267,7 +267,6 @@ static void dp8393x_update_irq(dp8393xState *s)
static void dp8393x_do_load_cam(dp8393xState *s)
{
-uint16_t data[8];
int width, size;
uint16_t index = 0;
@@ -277,13 +276,13 @@ static void dp8393x_do_load_cam(dp8393xState *s)
while (s->regs[SONIC_CDC] & 0x1f) {
/* Fill current entry */
address_space_rw(&s->as, dp8393x_cdp(s),
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
-s->cam[index][0] = dp8393x_get(s, width, data, 1) & 0xff;
-s->cam[index][1] = dp8393x_get(s, width, data, 1) >> 8;
-s->cam[index][2] = dp8393x_get(s, width, data, 2) & 0xff;
-s->cam[index][3] = dp8393x_get(s, width, data, 2) >> 8;
-s->cam[index][4] = dp8393x_get(s, width, data, 3) & 0xff;
-s->cam[index][5] = dp8393x_get(s, width, data, 3) >> 8;
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 0);
+s->cam[index][0] = dp8393x_get(s, width, 1) & 0xff;
+s->cam[index][1] = dp8393x_get(s, width, 1) >> 8;
+s->cam[index][2] = dp8393x_get(s, width, 2) & 0xff;
+s->cam[index][3] = dp8393x_get(s, width, 2) >> 8;
+s->cam[index][4] = dp8393x_get(s, width, 3) & 0xff;
+s->cam[index][5] = dp8393x_get(s, width, 3) >> 8;
DPRINTF("load cam[%d] with %02x%02x%02x%02x%02x%02x\n", index,
s->cam[index][0], s->cam[index][1], s->cam[index][2],
s->cam[index][3], s->cam[index][4], s->cam[index][5]);
@@ -295,8 +294,8 @@ static void dp8393x_do_load_cam(dp8393xState *s)
/* Read CAM enable */
address_space_rw(&s->as, dp8393x_cdp(s),
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
-s->regs[SONIC_CE] = dp8393x_get(s, width, data, 0);
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 0);
+s->regs[SONIC_CE] = dp8393x_get(s, width, 0);
DPRINTF("load cam done. cam enable mask 0x%04x\n", s->regs[SONIC_CE]);
/* Done */
@@ -307,20 +306,19 @@ static void dp8393x_do_load_cam(dp8393xState *s)
static void dp8393x_do_read_rra(dp8393xState *s)
{
-uint16_t data[8];
int width, size;
/* Read memory */
width = (s->regs[SONIC_DCR] & SONIC_DCR_DW) ? 2 : 1;
size = sizeof(uint16_t) * 4 * width;
address_space_rw(&s->as, dp8393x_rrp(s),
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)s->data, size, 0);
/* Update SONIC registers */
-s->regs[SONIC_CRBA0] = dp8393x_get(s, width, data, 0);
-s->regs[SONIC_CRBA1] = dp8393x_get(s, width, data, 1);
-s->regs[SONIC_RBWC0] = dp8393x_get(s, width, data, 2);
-s->regs[SONIC_RBWC1] = dp8393x_get(s, width, data, 3);
+s->regs[SONIC_CRBA0] = dp8393x_get(s, width, 0);
+s->regs[SONIC_CRBA1] = dp8393x_get(s, width, 1);
+s->regs[SONIC_RBWC0] = dp8393x_get(s, width, 2);
+s->regs[SONIC_RBWC1] = dp8393x_get(s, width, 3);
DPRINTF("CRBA0/1: 0x%04x/0x%04x, RBWC0/1: 0x%04x/0x%04x\n",
s->regs[SONIC_CRBA0], s->regs[SONIC_CRBA1],
s->regs[SONIC_RBWC0], s->regs[SONIC_RBWC1]);
@@ -417,7 +415,6 @@ static void dp8393x_do_receiver_disable(dp8393xState *s)
static void dp8393x_do_transmit_packets(dp8393xState *s)
{
NetClientState *nc = qemu_get_queue(s->nic);
-uint16_t data[12];
int widt
[PATCH 3/3] dp8393x: fix receiving buffer exhaustion
The card is not able to exit from exhaustion state, because
while the drive consumes the buffers, the RRP is incremented
(when the driver clears the ISR RBE bit), so it stays equal
to RWP, and while RRP == RWP, the card thinks it is always
in exhaustion state. So the driver consumes all the buffers,
but the card cannot receive new ones.
This patch fixes the problem by not incrementing RRP when
the driver clears the ISR RBE bit.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index b8c4473f99..21deb32456 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -304,7 +304,7 @@ static void dp8393x_do_load_cam(dp8393xState *s)
dp8393x_update_irq(s);
}
-static void dp8393x_do_read_rra(dp8393xState *s)
+static void dp8393x_do_read_rra(dp8393xState *s, int next)
{
int width, size;
@@ -323,19 +323,20 @@ static void dp8393x_do_read_rra(dp8393xState *s)
s->regs[SONIC_CRBA0], s->regs[SONIC_CRBA1],
s->regs[SONIC_RBWC0], s->regs[SONIC_RBWC1]);
-/* Go to next entry */
-s->regs[SONIC_RRP] += size;
+if (next) {
+/* Go to next entry */
+s->regs[SONIC_RRP] += size;
-/* Handle wrap */
-if (s->regs[SONIC_RRP] == s->regs[SONIC_REA]) {
-s->regs[SONIC_RRP] = s->regs[SONIC_RSA];
-}
+/* Handle wrap */
+if (s->regs[SONIC_RRP] == s->regs[SONIC_REA]) {
+s->regs[SONIC_RRP] = s->regs[SONIC_RSA];
+}
-/* Check resource exhaustion */
-if (s->regs[SONIC_RRP] == s->regs[SONIC_RWP])
-{
-s->regs[SONIC_ISR] |= SONIC_ISR_RBE;
-dp8393x_update_irq(s);
+/* Check resource exhaustion */
+if (s->regs[SONIC_RRP] == s->regs[SONIC_RWP]) {
+s->regs[SONIC_ISR] |= SONIC_ISR_RBE;
+dp8393x_update_irq(s);
+}
}
/* Done */
@@ -549,7 +550,7 @@ static void dp8393x_do_command(dp8393xState *s, uint16_t
command)
if (command & SONIC_CR_RST)
dp8393x_do_software_reset(s);
if (command & SONIC_CR_RRRA)
-dp8393x_do_read_rra(s);
+dp8393x_do_read_rra(s, 1);
if (command & SONIC_CR_LCAM)
dp8393x_do_load_cam(s);
}
@@ -640,7 +641,7 @@ static void dp8393x_write(void *opaque, hwaddr addr,
uint64_t data,
data &= s->regs[reg];
s->regs[reg] &= ~data;
if (data & SONIC_ISR_RBE) {
-dp8393x_do_read_rra(s);
+dp8393x_do_read_rra(s, 0);
}
dp8393x_update_irq(s);
if (dp8393x_can_receive(s->nic->ncs)) {
@@ -840,7 +841,7 @@ static ssize_t dp8393x_receive(NetClientState *nc, const
uint8_t * buf,
if (s->regs[SONIC_RCR] & SONIC_RCR_LPKT) {
/* Read next RRA */
-dp8393x_do_read_rra(s);
+dp8393x_do_read_rra(s, 1);
}
}
--
2.21.0
[PATCH 0/3] dp8393x: fix problems detected with Quadra 800 machine
This series starts with a cleanup of the DMA buffer, moving it from the stack to the state structure. The following patch allows to negociate the IP address with the DHCP server. The last one fixes the buffer exhaustion case. With this series Q800 networking card is fully functionnal. Laurent Vivier (3): dp8393x: put the DMA buffer in the state structure dp8393x: fix dp8393x_receive() dp8393x: fix receiving buffer exhaustion hw/net/dp8393x.c | 136 +++ 1 file changed, 66 insertions(+), 70 deletions(-) -- 2.21.0
Re: [PATCH] Makefile: install bios-microvm like other binary blobs
On Sat, Nov 2, 2019 at 12:43 PM Philippe Mathieu-Daudé wrote: > > From: Bruce Rogers > > Commit 0d5fae3e52e introduced bios-microvm.bin but forgot to add > it to the list of blobs being installed. > Add it to the list of BLOBS that get installed. > > Fixes: 0d5fae3e52e "roms: add microvm-bios (qboot) as binary" > Signed-off-by: Bruce Rogers > [PMD: Reworded description] > Signed-off-by: Philippe Mathieu-Daudé > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The patch LGTM: Reviewed-by: Stefano Garzarella Thanks, Stefano > > diff --git a/Makefile b/Makefile > index bd6376d295..755aa6c5f5 100644 > --- a/Makefile > +++ b/Makefile > @@ -770,7 +770,7 @@ de-ch es fo fr-ca hu ja mk pt sl tr \ > bepocz > > ifdef INSTALL_BLOBS > -BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \ > +BLOBS=bios.bin bios-256k.bin bios-microvm.bin sgabios.bin vgabios.bin > vgabios-cirrus.bin \ > vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \ > vgabios-ramfb.bin vgabios-bochs-display.bin vgabios-ati.bin \ > ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin > QEMU,cgthree.bin \ > -- > 2.21.0 >
Re: [RFC v2 12/22] intel_iommu: add present bit check for pasid table entries
On Thu, Oct 24, 2019 at 08:34:33AM -0400, Liu Yi L wrote: > The present bit check for pasid entry (pe) and pasid directory > entry (pdire) were missed in previous commits as fpd bit check > doesn't require present bit as "Set". This patch adds the present > bit check for callers which wants to get a valid pe/pdire. > > Cc: Kevin Tian > Cc: Jacob Pan > Cc: Peter Xu > Cc: Yi Sun > Signed-off-by: Liu Yi L Reviewed-by: Peter Xu -- Peter Xu
Re: [RFC v2 11/22] intel_iommu: process pasid cache invalidation
On Thu, Oct 24, 2019 at 08:34:32AM -0400, Liu Yi L wrote:
> This patch adds PASID cache invalidation handling. When guest enabled
> PASID usages (e.g. SVA), guest software should issue a proper PASID
> cache invalidation when caching-mode is exposed. This patch only adds
> the draft handling of pasid cache invalidation. Detailed handling will
> be added in subsequent patches.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Peter Xu
> Cc: Yi Sun
> Signed-off-by: Liu Yi L
> ---
> hw/i386/intel_iommu.c | 66
> ++
> hw/i386/intel_iommu_internal.h | 12
> hw/i386/trace-events | 3 ++
> 3 files changed, 76 insertions(+), 5 deletions(-)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 88b843f..84ff6f0 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -2335,6 +2335,63 @@ static bool vtd_process_iotlb_desc(IntelIOMMUState *s,
> VTDInvDesc *inv_desc)
> return true;
> }
>
> +static int vtd_pasid_cache_dsi(IntelIOMMUState *s, uint16_t domain_id)
> +{
> +return 0;
> +}
> +
> +static int vtd_pasid_cache_psi(IntelIOMMUState *s,
> + uint16_t domain_id, uint32_t pasid)
> +{
> +return 0;
> +}
> +
> +static int vtd_pasid_cache_gsi(IntelIOMMUState *s)
> +{
> +return 0;
> +}
> +
> +static bool vtd_process_pasid_desc(IntelIOMMUState *s,
> + VTDInvDesc *inv_desc)
> +{
> +uint16_t domain_id;
> +uint32_t pasid;
> +int ret = 0;
> +
> +if ((inv_desc->val[0] & VTD_INV_DESC_PASIDC_RSVD_VAL0) ||
> +(inv_desc->val[1] & VTD_INV_DESC_PASIDC_RSVD_VAL1) ||
> +(inv_desc->val[2] & VTD_INV_DESC_PASIDC_RSVD_VAL2) ||
> +(inv_desc->val[3] & VTD_INV_DESC_PASIDC_RSVD_VAL3)) {
> +error_report_once("non-zero-field-in-pc_inv_desc hi: 0x%" PRIx64
> + " lo: 0x%" PRIx64, inv_desc->val[1], inv_desc->val[0]);
> +return false;
> +}
> +
> +domain_id = VTD_INV_DESC_PASIDC_DID(inv_desc->val[0]);
> +pasid = VTD_INV_DESC_PASIDC_PASID(inv_desc->val[0]);
> +
> +switch (inv_desc->val[0] & VTD_INV_DESC_PASIDC_G) {
> +case VTD_INV_DESC_PASIDC_DSI:
> +ret = vtd_pasid_cache_dsi(s, domain_id);
> +break;
> +
> +case VTD_INV_DESC_PASIDC_PASID_SI:
> +ret = vtd_pasid_cache_psi(s, domain_id, pasid);
> +break;
> +
> +case VTD_INV_DESC_PASIDC_GLOBAL:
> +ret = vtd_pasid_cache_gsi(s);
> +break;
> +
> +default:
> +error_report_once("invalid-inv-granu-in-pc_inv_desc hi: 0x%" PRIx64
> + " lo: 0x%" PRIx64, inv_desc->val[1], inv_desc->val[0]);
> +return false;
> +}
> +
> +return (ret == 0) ? true : false;
> +}
> +
> static bool vtd_process_inv_iec_desc(IntelIOMMUState *s,
> VTDInvDesc *inv_desc)
> {
> @@ -2441,12 +2498,11 @@ static bool vtd_process_inv_desc(IntelIOMMUState *s)
> }
> break;
>
> -/*
> - * TODO: the entity of below two cases will be implemented in future
> series.
> - * To make guest (which integrates scalable mode support patch set in
> - * iommu driver) work, just return true is enough so far.
> - */
> case VTD_INV_DESC_PC:
> +trace_vtd_inv_desc("pasid-cache", inv_desc.val[1], inv_desc.val[0]);
Could be helpful if you dump [2|3] together here...
> +if (!vtd_process_pasid_desc(s, &inv_desc)) {
> +return false;
> +}
> break;
>
> case VTD_INV_DESC_PIOTLB:
> diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
> index 8668771..c6cb28b 100644
> --- a/hw/i386/intel_iommu_internal.h
> +++ b/hw/i386/intel_iommu_internal.h
> @@ -445,6 +445,18 @@ typedef union VTDInvDesc VTDInvDesc;
> #define VTD_SPTE_LPAGE_L4_RSVD_MASK(aw) \
> (0x880ULL | ~(VTD_HAW_MASK(aw) | VTD_SL_IGN_COM))
>
> +#define VTD_INV_DESC_PASIDC_G (3ULL << 4)
> +#define VTD_INV_DESC_PASIDC_PASID(val) (((val) >> 32) & 0xfULL)
> +#define VTD_INV_DESC_PASIDC_DID(val) (((val) >> 16) & VTD_DOMAIN_ID_MASK)
> +#define VTD_INV_DESC_PASIDC_RSVD_VAL0 0xfff0ffc0ULL
Nit: Mind to comment here that bit 9-11 is marked as zero rather than
reserved? This seems to work but if bit 9-11 can be non-zero in some
other descriptors then it would be clearer to define it as
0xfff0f1c0ULL then explicitly check bits 9-11.
Otherwise looks good to me.
> +#define VTD_INV_DESC_PASIDC_RSVD_VAL1 0xULL
> +#define VTD_INV_DESC_PASIDC_RSVD_VAL2 0xULL
> +#define VTD_INV_DESC_PASIDC_RSVD_VAL3 0xULL
> +
> +#define VTD_INV_DESC_PASIDC_DSI(0ULL << 4)
> +#define VTD_INV_DESC_PASIDC_PASID_SI (1ULL << 4)
> +#define VTD_INV_DESC_PASIDC_GLOBAL (3ULL << 4)
> +
> /* Information about page-selective IOTLB invalidate */
> struct VTDIOTLBPageInvInfo {
> uint16_t domain_id;
> diff --git a/hw/i386/trac
[PATCH] mos6522: fix T1 and T2 timers
With the Quadra 800 emulation, mos6522 timers processing can consume
until 70% of the host CPU time with an idle guest (I guess the problem
should also happen with PowerMac emulation).
On a recent system, it can be painless (except if you look at top), but
on an old host like a PowerMac G5 the guest kernel can be terribly slow
during the boot sequence (for instance, unpacking initramfs can take 15
seconds rather than only 3 seconds).
We can avoid this CPU overload by enabling QEMU internal timers only if
the mos6522 counter interrupts are enabled. Sometime the guest kernel
wants to read the counters values, but we don't need the timers to
update the counters.
With this patch applied, an idle Q800 consumes only 3% of host CPU time
(and the guest can boot in a decent time).
Signed-off-by: Laurent Vivier
---
hw/misc/mos6522.c | 67 ---
1 file changed, 52 insertions(+), 15 deletions(-)
diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index 57f13db266..aa3bfe1afd 100644
--- a/hw/misc/mos6522.c
+++ b/hw/misc/mos6522.c
@@ -38,8 +38,10 @@
/* XXX: implement all timer modes */
-static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
- int64_t current_time);
+static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
+ int64_t current_time);
+static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
+ int64_t current_time);
static void mos6522_update_irq(MOS6522State *s)
{
@@ -98,7 +100,11 @@ static void set_counter(MOS6522State *s, MOS6522Timer *ti,
unsigned int val)
trace_mos6522_set_counter(1 + ti->index, val);
ti->load_time = get_load_time(s, ti);
ti->counter_value = val;
-mos6522_timer_update(s, ti, ti->load_time);
+if (ti->index == 0) {
+mos6522_timer1_update(s, ti, ti->load_time);
+} else {
+mos6522_timer2_update(s, ti, ti->load_time);
+}
}
static int64_t get_next_irq_time(MOS6522State *s, MOS6522Timer *ti,
@@ -130,19 +136,34 @@ static int64_t get_next_irq_time(MOS6522State *s,
MOS6522Timer *ti,
trace_mos6522_get_next_irq_time(ti->latch, d, next_time - d);
next_time = muldiv64(next_time, NANOSECONDS_PER_SECOND, ti->frequency) +
ti->load_time;
+
if (next_time <= current_time) {
next_time = current_time + 1;
}
return next_time;
}
-static void mos6522_timer_update(MOS6522State *s, MOS6522Timer *ti,
+static void mos6522_timer1_update(MOS6522State *s, MOS6522Timer *ti,
+ int64_t current_time)
+{
+if (!ti->timer) {
+return;
+}
+if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
+timer_del(ti->timer);
+} else {
+ti->next_irq_time = get_next_irq_time(s, ti, current_time);
+timer_mod(ti->timer, ti->next_irq_time);
+}
+}
+
+static void mos6522_timer2_update(MOS6522State *s, MOS6522Timer *ti,
int64_t current_time)
{
if (!ti->timer) {
return;
}
-if (ti->index == 0 && (s->acr & T1MODE) != T1MODE_CONT) {
+if ((s->ier & T2_INT) == 0) {
timer_del(ti->timer);
} else {
ti->next_irq_time = get_next_irq_time(s, ti, current_time);
@@ -155,7 +176,7 @@ static void mos6522_timer1(void *opaque)
MOS6522State *s = opaque;
MOS6522Timer *ti = &s->timers[0];
-mos6522_timer_update(s, ti, ti->next_irq_time);
+mos6522_timer1_update(s, ti, ti->next_irq_time);
s->ifr |= T1_INT;
mos6522_update_irq(s);
}
@@ -165,7 +186,7 @@ static void mos6522_timer2(void *opaque)
MOS6522State *s = opaque;
MOS6522Timer *ti = &s->timers[1];
-mos6522_timer_update(s, ti, ti->next_irq_time);
+mos6522_timer2_update(s, ti, ti->next_irq_time);
s->ifr |= T2_INT;
mos6522_update_irq(s);
}
@@ -204,7 +225,16 @@ uint64_t mos6522_read(void *opaque, hwaddr addr, unsigned
size)
{
MOS6522State *s = opaque;
uint32_t val;
+int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+if (now >= s->timers[0].next_irq_time) {
+mos6522_timer1_update(s, &s->timers[0], now);
+s->ifr |= T1_INT;
+}
+if (now >= s->timers[1].next_irq_time) {
+mos6522_timer2_update(s, &s->timers[1], now);
+s->ifr |= T2_INT;
+}
switch (addr) {
case VIA_REG_B:
val = s->b;
@@ -299,8 +329,8 @@ void mos6522_write(void *opaque, hwaddr addr, uint64_t val,
unsigned size)
break;
case VIA_REG_T1CL:
s->timers[0].latch = (s->timers[0].latch & 0xff00) | val;
-mos6522_timer_update(s, &s->timers[0],
- qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL));
+mos6522_timer1_update(s, &s->timers[0],
+ qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL));
break;
case VIA_REG_T1CH:
s->timers[0].latch = (s->timers[0].lat
[PATCH] Makefile: install bios-microvm like other binary blobs
From: Bruce Rogers Commit 0d5fae3e52e introduced bios-microvm.bin but forgot to add it to the list of blobs being installed. Add it to the list of BLOBS that get installed. Fixes: 0d5fae3e52e "roms: add microvm-bios (qboot) as binary" Signed-off-by: Bruce Rogers [PMD: Reworded description] Signed-off-by: Philippe Mathieu-Daudé --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index bd6376d295..755aa6c5f5 100644 --- a/Makefile +++ b/Makefile @@ -770,7 +770,7 @@ de-ch es fo fr-ca hu ja mk pt sl tr \ bepocz ifdef INSTALL_BLOBS -BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \ +BLOBS=bios.bin bios-256k.bin bios-microvm.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \ vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \ vgabios-ramfb.bin vgabios-bochs-display.bin vgabios-ati.bin \ ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin \ -- 2.21.0
Re: [PATCH v5 0/2] RTC support for QEMU RISC-V virt machine
On Tue, 29 Oct 2019 at 13:25, Alistair Francis wrote: > > On Fri, Oct 25, 2019 at 6:28 AM Anup Patel wrote: > > > > This series adds RTC device to QEMU RISC-V virt machine. We have > > selected Goldfish RTC device model for this. It's a pretty simple > > synthetic device with few MMIO registers and no dependency external > > clock. The driver for Goldfish RTC is already available in Linux so > > we just need to enable it in Kconfig for RISCV and also update Linux > > defconfigs. > > > > We have tested this series with Linux-5.4-rc4 plus defconfig changes > > available in 'goldfish_rtc_v2' branch of: > > https://github.com/avpatel/linux.git > > @Peter Maydell this has been reviewed, do you mind taking this in you > next PR? I don't see a maintainer for hw/rtc. Generally devices used by a single architecture should go via the tree of the maintainer who handles that architecture -- in this case that's riscv. (The reason is that it's only riscv folks who can test whether the device works in the machine model, and only riscv folks who can reasonably review whether the device is the right way of implementing the functionality for them.) thanks -- PMM
Re: [PATCH] linux-user: Support for NETLINK socket options
Le 29/10/2019 à 23:43, Josh Kunz a écrit :
> This change includes support for all AF_NETLINK socket options up to about
> kernel version 5.4 (5.4 is not formally released at the time of writing).
> Socket options that were introduced in kernel versions before the oldest
> currently stable kernel version are guarded by kernel version macros.
>
> This change has been built under gcc 8.3, and clang 9.0, and it passes
> `make check`. The netlink options have been tested by emulating some
> non-trival software that uses NETLINK socket options, but they have
> not been exaustively verified.
>
> Signed-off-by: Josh Kunz
> ---
> linux-user/syscall.c | 98
> 1 file changed, 98 insertions(+)
...
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0)
> +case NETLINK_LIST_MEMBERSHIPS:
> +{
> +if (get_user_u32(len, optlen)) {
> +return -TARGET_EFAULT;
> +}
> +if (len < 0) {
> +return -TARGET_EINVAL;
> +}
> +uint32_t *results = lock_user(VERIFY_WRITE, optval_addr, len, 1);
Please put the declaration of "results" at the beginning of the block.
See CODING_STYLE file, "Declarations"
> +if (!results) {
> +return -TARGET_EFAULT;
> +}
> +lv = len;
> +ret = get_errno(getsockopt(sockfd, level, optname, results,
> &lv));
> +if (ret < 0) {
> +unlock_user(results, optval_addr, 0);
> +return ret;
> +}
> +/* swap host endianess to target endianess. */
> +for (int i = 0; i < (len / sizeof(uint32_t)); i++) {
Put the declaration of "i" at the beginning of the block.
Otherwise, it looks good.
Thanks,
Laurent
Re: [PATCH v4] smb daemon get additional command line parameters from env variable
Jordi Pujol, le sam. 02 nov. 2019 08:41:52 +0100, a ecrit:
> @@ -909,6 +910,12 @@ static int slirp_smb(SlirpState* s, cons
> CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
> g_free(smb_conf);
>
> +options = g_getenv("SMBDOPTIONS");
> +if (options) {
> +smb_cmdline = g_strdup_printf("%s %s", smb_cmdline, options);
> +g_free(options);
> +}
Again, what g_getenv mustn't be freed. I believe you even get a warning
about it: g_getenv returns a const gchar *.
The old value of smb_cmdline, however, has to be freed, otherwise that's
a memory leak.
Samuel
Re: [PATCH v4] smb daemon get additional command line parameters from env variable
From: Jordi Pujol Palomer
Date: Sat, 2 Nov 2019 08:54:14 +0200
Subject: [PATCH v4] QEMU samba daemon: additional command line options
The smbd daemon takes additional command line options
from environment variable SMBDOPTIONS.
Set the environment variable SMBDOPTIONS before executing qemu.
Example:
export SMBDOPTIONS="--option='server min protocol=CORE' -d 4"
Signed-off-by: Jordi Pujol Palomer
---
--- qemu-4.1-a/net/slirp.c
+++ qemu_4.1-b/net/slirp.c
@@ -834,6 +834,7 @@ static int slirp_smb(SlirpState* s, cons
char *smb_cmdline;
struct passwd *passwd;
FILE *f;
+char *options;
passwd = getpwuid(geteuid());
if (!passwd) {
@@ -909,6 +910,12 @@ static int slirp_smb(SlirpState* s, cons
CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
g_free(smb_conf);
+options = g_getenv("SMBDOPTIONS");
+if (options) {
+smb_cmdline = g_strdup_printf("%s %s", smb_cmdline, options);
+g_free(options);
+}
+
if (slirp_add_exec(s->slirp, smb_cmdline, &vserver_addr, 139) < 0 ||
slirp_add_exec(s->slirp, smb_cmdline, &vserver_addr, 445) < 0) {
slirp_smb_cleanup(s);
RE: [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM
> From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Friday, November 1, 2019 4:10 PM > > > On 2019/11/1 下午4:04, Jason Wang wrote: > > > > On 2019/11/1 下午3:46, Tian, Kevin wrote: > >>> From: Jason Wang [mailto:jasow...@redhat.com] > >>> Sent: Friday, November 1, 2019 3:30 PM > >>> > >>> > >>> On 2019/10/31 下午10:07, Liu, Yi L wrote: > > From: Jason Wang [mailto:jasow...@redhat.com] > > Sent: Thursday, October 31, 2019 5:33 AM > > Subject: Re: [RFC v2 00/22] intel_iommu: expose Shared Virtual > >>> Addressing to VM > > > > On 2019/10/25 下午6:12, Tian, Kevin wrote: > >>> From: Jason Wang [mailto:jasow...@redhat.com] > >>> Sent: Friday, October 25, 2019 5:49 PM > >>> > >>> > >>> On 2019/10/24 下午8:34, Liu Yi L wrote: > Shared virtual address (SVA), a.k.a, Shared virtual memory > (SVM) on > Intel platforms allow address space sharing between device DMA > >>> and > >>> applications. > >>> > >>> > >>> Interesting, so the below figure demonstrates the case of VM. I > >>> wonder how much differences if we compare it with doing SVM > >>> between > >>> device and an ordinary process (e.g dpdk)? > >>> > >>> Thanks > >> One difference is that ordinary process requires only stage-1 > >> translation, while VM requires nested translation. > > A silly question, then I believe there's no need for VFIO DMA API > > in this > >>> case consider > > the page table is shared between MMU and IOMMU? > Echo Kevin's reply. We use nested translation here. For stage-1, > yes, no > >>> need to use > VFIO DMA API. For stage-2, we still use VFIO DMA API to program the > >>> GPA->HPA > mapping to host. :-) > >>> > >>> Cool, two more questions: > >>> > >>> - Can EPT shares its page table with IOMMU L2? > >> yes, their formats are compatible. > >> > >>> - Similar to EPT, when GPA->HPA (actually HVA->HPA) is modified by > mm, > >>> VFIO need to use MMU notifier do modify L2 accordingly besides DMA > API? > >>> > >> VFIO devices need to pin-down guest memory pages that are mapped > >> in IOMMU. So notifier is not required since mm won't change the > mapping > >> for those pages. > > > > > > The GUP tends to lead a lot of issues, we may consider to allow > > userspace to choose to not pin them in the future. > > > Btw, I'm asking since I see MMU notifier is used by intel-svm.c to flush > IOTLB. (I don't see any users in kernel source that use that API though > e.g intel_svm_bind_mm()). > intel-svm.c requires MMU notifier to invalidate IOTLB upon any change on the CPU page table, when the latter is shared with device in SVA case. But for VFIO usage, which is based on stage2, the map/unmap requests explicitly come from userspace. there is no need to sync with mm. Thanks Kevin
