Re: pixman_blt on aarch64
On Sun, 5 Feb 2023, BALATON Zoltan wrote: On Sun, 5 Feb 2023, Richard Henderson wrote: On 2/4/23 06:57, BALATON Zoltan wrote: This has just bounced, I hoped to still be able to post after moderation but now I'm resending it after subscribing to the pixman list. Meanwhile I've found this ticket as well: https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/71 See the rest of the message below. Looks like this is being worked on but I'm not sure how far is it from getting resolved. Any info on that? Please try this: https://gitlab.freedesktop.org/rth7680/pixman/-/tree/general It provides a pure C version for ultimate fallback. Unfortunately, there are no test cases for this, nor documentation. Thanks, I don't have hardware to test this but maybe Akihiko or somebody else here cam try. Do you think pixman_fill won't have the same problem? It seems to have at least a fast_path implementation but I'm not sure how pixman selects these. We have tried the branch above and while it does make it better and usable in 16bit mode, 8bit is still missing (no wonder as it does not have that implemented but the AmigaOS driver only allows 16bit and 8bit with the sm501 device this is used in but probably that's not important when 16 bit works). Even in 16bit more there were some graphics problems seen but that may need some more checking to make sure it's not some other change as the report was not clear if that worked before. I've asked to check the changes in https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/71 next to see if that would work better. Regards, BALATON Zoltan
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
在2023年2月17日二月 下午6:57，Thomas Huth写道：
> On 17/02/2023 18.43, Philippe Mathieu-Daudé wrote:
>> (Cc'ing Huacai & Jiaxun).
>>
>> On 17/2/23 17:38, Paolo Bonzini wrote:
>>> On 2/17/23 11:47, Daniel P. Berrangé wrote:
On Fri, Feb 17, 2023 at 11:36:41AM +0100, Markus Armbruster wrote:
> I feel the discussion petered out without a conclusion.
>
> I don't think letting the status quo win by inertia is a good outcome
> here.
>
> Which 32-bit hosts are still useful, and why?
Which 32-bit hosts does Linux still provide KVM support for.
>>>
>>> All except ARM: MIPS, x86, PPC and RISC-V.
>>>
>>> I would like to remove x86, but encountered some objections.
>>>
>>> MIPS, nobody is really using it I think.
>>
>> 32-bit was added in 2014, commit 222e7d11e7 ("target-mips: Enable KVM
>> support in build system"). I'm not aware of anybody using it (even
>> testing it). I don't have hardware to test it (neither time).
>
> Could you maybe suggest a kernel patch to remove it, to see what happens?
> ... if nobody objects to the removal of the 32-bit MIPS KVM kernel support
> and the patch gets merged, that would help us in the long run, I think.
I’m still occasionally testing 32-bit MIPS KVM support with MIPS P5600.
It works just fine so there is no need for further maintenance work.
I’d be sad to see the support go but I can live with it.
There are commercial users for MIPS 32 KVM but they’re all running customized
downstream QEMU so I guess it’s fine.
Thanks
- Jiaxun
>
> Thanks,
>Thomas
--
- Jiaxun
Re: [PATCH 05/12] hw/i2c/smbus_ich9: Inline ich9_smb_init() and remove it
On Mon, Feb 13, 2023 at 06:30:26PM +0100, Bernhard Beschow wrote:
> ich9_smb_init() is a legacy init function, so modernize the code.
>
> Note that the smb_io_base parameter was unused.
Acked-by: Corey Minyard
>
> Signed-off-by: Bernhard Beschow
> ---
> include/hw/i386/ich9.h | 1 -
> hw/i2c/smbus_ich9.c| 13 +++--
> hw/i386/pc_q35.c | 11 ---
> 3 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
> index 05464f6965..52ea116f44 100644
> --- a/include/hw/i386/ich9.h
> +++ b/include/hw/i386/ich9.h
> @@ -9,7 +9,6 @@
> #include "qom/object.h"
>
> void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
> -I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
>
> void ich9_generate_smi(void);
>
> diff --git a/hw/i2c/smbus_ich9.c b/hw/i2c/smbus_ich9.c
> index d29c0f6ffa..f0dd3cb147 100644
> --- a/hw/i2c/smbus_ich9.c
> +++ b/hw/i2c/smbus_ich9.c
> @@ -105,6 +105,9 @@ static void ich9_smbus_realize(PCIDevice *d, Error **errp)
> pm_smbus_init(>qdev, >smb, false);
> pci_register_bar(d, ICH9_SMB_SMB_BASE_BAR, PCI_BASE_ADDRESS_SPACE_IO,
> >smb.io);
> +
> +s->smb.set_irq = ich9_smb_set_irq;
> +s->smb.opaque = s;
> }
>
> static void build_ich9_smb_aml(AcpiDevAmlIf *adev, Aml *scope)
> @@ -137,16 +140,6 @@ static void ich9_smb_class_init(ObjectClass *klass, void
> *data)
> adevc->build_dev_aml = build_ich9_smb_aml;
> }
>
> -I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base)
> -{
> -PCIDevice *d =
> -pci_create_simple_multifunction(bus, devfn, true,
> TYPE_ICH9_SMB_DEVICE);
> -ICH9SMBState *s = ICH9_SMB_DEVICE(d);
> -s->smb.set_irq = ich9_smb_set_irq;
> -s->smb.opaque = s;
> -return s->smb.smbus;
> -}
> -
> static const TypeInfo ich9_smb_info = {
> .name = TYPE_ICH9_SMB_DEVICE,
> .parent = TYPE_PCI_DEVICE,
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 4af8474f31..85ba8ed951 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -316,10 +316,15 @@ static void pc_q35_init(MachineState *machine)
> }
>
> if (pcms->smbus_enabled) {
> +PCIDevice *smb;
> +
> /* TODO: Populate SPD eeprom data. */
> -pcms->smbus = ich9_smb_init(host_bus,
> -PCI_DEVFN(ICH9_SMB_DEV, ICH9_SMB_FUNC),
> -0xb100);
> +smb = pci_create_simple_multifunction(host_bus,
> + PCI_DEVFN(ICH9_SMB_DEV,
> +ICH9_SMB_FUNC),
> + true, TYPE_ICH9_SMB_DEVICE);
> +pcms->smbus = I2C_BUS(qdev_get_child_bus(DEVICE(smb), "i2c"));
> +
> smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
> }
>
> --
> 2.39.1
>
>
Re: [PATCH v6 2/4] target/riscv: implement Zicboz extension
On 2/17/23 23:28, Daniel Henrique Barboza wrote:
"A cache-block zero instruction is permitted to access the specified cache
block whenever
a store instruction is permitted to access the corresponding physical addresses
and when
the PMAs indicate that cache-block zero instructions are a supported access
type. If access
to the cache block is not permitted, a cache-block zero instruction raises a
store page fault
or store guest-page fault exception if address translation does not permit
write access or
raises a store access fault exception otherwise. During address translation,
the instruction
also checks the accessed and dirty bits and may either raise an exception or
set the bits as
required."
By the way, I think the documentation should specify what happens if the page is *not*
accessible. Is badaddr = {rN, aligned(rN), unspecified, but somewhere in the block}?
r~
[PATCH 3/4] ui: add helpers for virtio-multitouch events
Add helpers for generating Multi-touch events from the UI backends that
can be sent to the guest through a virtio-multitouch device.
Signed-off-by: Sergio Lopez
---
include/ui/input.h | 5 +
ui/input.c | 36
2 files changed, 41 insertions(+)
diff --git a/include/ui/input.h b/include/ui/input.h
index 2a3dffd417..c37251e1e9 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -64,6 +64,11 @@ int qemu_input_scale_axis(int value,
void qemu_input_queue_rel(QemuConsole *src, InputAxis axis, int value);
void qemu_input_queue_abs(QemuConsole *src, InputAxis axis, int value,
int min_in, int max_in);
+void qemu_input_queue_mtt(QemuConsole *src, InputMultitouchType type, int slot,
+ int tracking_id);
+void qemu_input_queue_mtt_abs(QemuConsole *src, InputAxis axis, int value,
+ int min_in, int max_in,
+ int slot, int tracking_id);
void qemu_input_check_mode_change(void);
void qemu_add_mouse_mode_change_notifier(Notifier *notify);
diff --git a/ui/input.c b/ui/input.c
index f788db20f7..34331b7b0b 100644
--- a/ui/input.c
+++ b/ui/input.c
@@ -547,6 +547,42 @@ void qemu_input_queue_abs(QemuConsole *src, InputAxis
axis, int value,
qemu_input_event_send(src, );
}
+void qemu_input_queue_mtt(QemuConsole *src, InputMultitouchType type,
+ int slot, int tracking_id)
+{
+InputMultitouchEvent mtt = {
+.type = type,
+.slot = slot,
+.tracking_id = tracking_id,
+};
+InputEvent evt = {
+.type = INPUT_EVENT_KIND_MTT,
+.u.mtt.data = ,
+};
+
+qemu_input_event_send(src, );
+}
+
+void qemu_input_queue_mtt_abs(QemuConsole *src, InputAxis axis, int value,
+ int min_in, int max_in, int slot, int
tracking_id)
+{
+InputMultitouchEvent mtt = {
+.type = INPUT_MULTITOUCH_TYPE_DATA,
+.slot = slot,
+.tracking_id = tracking_id,
+.axis = axis,
+.value = qemu_input_scale_axis(value, min_in, max_in,
+ INPUT_EVENT_ABS_MIN,
+ INPUT_EVENT_ABS_MAX),
+};
+InputEvent evt = {
+.type = INPUT_EVENT_KIND_MTT,
+.u.mtt.data = ,
+};
+
+qemu_input_event_send(src, );
+}
+
void qemu_input_check_mode_change(void)
{
static int current_is_absolute;
--
2.38.1
[PATCH 4/4] ui/gtk: enable backend to send multi-touch events
GTK3 provides the infrastructure to receive and process multi-touch
events through the "touch-event" signal and the GdkEventTouch type.
Make use of it to transpose events from the host to the guest.
This allows users of machines with hardware capable of receiving
multi-touch events to run guests that can also receive those events
and interpret them as gestures, when appropriate.
An example of this in action can be seen here:
https://fosstodon.org/@slp/109545849296546767
Signed-off-by: Sergio Lopez
---
ui/gtk.c | 84
1 file changed, 84 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index fd82e9b1ca..bf1e7f086d 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -130,6 +130,13 @@ typedef struct VCChardev VCChardev;
DECLARE_INSTANCE_CHECKER(VCChardev, VC_CHARDEV,
TYPE_CHARDEV_VC)
+struct touch_slot {
+int x;
+int y;
+int tracking_id;
+};
+static struct touch_slot touch_slots[INPUT_EVENT_SLOTS_MAX];
+
bool gtk_use_gl_area;
static void gd_grab_pointer(VirtualConsole *vc, const char *reason);
@@ -1058,6 +1065,74 @@ static gboolean gd_scroll_event(GtkWidget *widget,
GdkEventScroll *scroll,
}
+static gboolean gd_touch_event(GtkWidget *widget, GdkEventTouch *touch,
+ void *opaque)
+{
+VirtualConsole *vc = opaque;
+struct touch_slot *slot;
+uint64_t num_slot = (uint64_t) touch->sequence;
+int update;
+int type = -1;
+int i;
+
+if (num_slot >= INPUT_EVENT_SLOTS_MAX) {
+return FALSE;
+}
+
+slot = _slots[num_slot];
+slot->x = touch->x;
+slot->y = touch->y;
+
+switch (touch->type) {
+case GDK_TOUCH_BEGIN:
+type = INPUT_MULTITOUCH_TYPE_BEGIN;
+slot->tracking_id = num_slot;
+break;
+case GDK_TOUCH_UPDATE:
+type = INPUT_MULTITOUCH_TYPE_UPDATE;
+break;
+case GDK_TOUCH_END:
+case GDK_TOUCH_CANCEL:
+type = INPUT_MULTITOUCH_TYPE_END;
+break;
+default:
+fprintf(stderr, "%s: unexpected touch event\n", __func__);
+}
+
+for (i = 0; i < INPUT_EVENT_SLOTS_MAX; ++i) {
+if (i == num_slot) {
+update = type;
+} else {
+update = INPUT_MULTITOUCH_TYPE_UPDATE;
+}
+
+slot = _slots[i];
+
+if (slot->tracking_id == -1) {
+continue;
+}
+
+if (update == INPUT_MULTITOUCH_TYPE_END) {
+slot->tracking_id = -1;
+qemu_input_queue_mtt(vc->gfx.dcl.con, update, i,
slot->tracking_id);
+} else {
+qemu_input_queue_mtt(vc->gfx.dcl.con, update, i,
slot->tracking_id);
+qemu_input_queue_btn(vc->gfx.dcl.con, INPUT_BUTTON_TOUCH, true);
+qemu_input_queue_mtt_abs(vc->gfx.dcl.con,
+ INPUT_AXIS_X, (int) slot->x,
+ 0, surface_width(vc->gfx.ds),
+ i, slot->tracking_id);
+qemu_input_queue_mtt_abs(vc->gfx.dcl.con,
+ INPUT_AXIS_Y, (int) slot->y,
+ 0, surface_height(vc->gfx.ds),
+ i, slot->tracking_id);
+}
+qemu_input_event_sync();
+}
+
+return TRUE;
+}
+
static const guint16 *gd_get_keymap(size_t *maplen)
{
GdkDisplay *dpy = gdk_display_get_default();
@@ -1977,6 +2052,8 @@ static void gd_connect_vc_gfx_signals(VirtualConsole *vc)
G_CALLBACK(gd_key_event), vc);
g_signal_connect(vc->gfx.drawing_area, "key-release-event",
G_CALLBACK(gd_key_event), vc);
+g_signal_connect(vc->gfx.drawing_area, "touch-event",
+ G_CALLBACK(gd_touch_event), vc);
g_signal_connect(vc->gfx.drawing_area, "enter-notify-event",
G_CALLBACK(gd_enter_event), vc);
@@ -2086,6 +2163,7 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s,
VirtualConsole *vc,
GSList *group, GtkWidget *view_menu)
{
bool zoom_to_fit = false;
+int i;
vc->label = qemu_console_get_label(con);
vc->s = s;
@@ -2133,6 +2211,7 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s,
VirtualConsole *vc,
GDK_BUTTON_PRESS_MASK |
GDK_BUTTON_RELEASE_MASK |
GDK_BUTTON_MOTION_MASK |
+ GDK_TOUCH_MASK |
GDK_ENTER_NOTIFY_MASK |
GDK_LEAVE_NOTIFY_MASK |
GDK_SCROLL_MASK |
@@ -2168,6 +2247,11 @@ static GSList *gd_vc_gfx_init(GtkDisplayState *s,
VirtualConsole *vc,
s->free_scale = true;
}
+for (i = 0; i < INPUT_EVENT_SLOTS_MAX; i++) {
+struct touch_slot *slot = _slots[i];
+slot->tracking_id = -1;
+}
+
return group;
}
--
2.38.1
[PATCH 1/4] virtio-input: generalize virtio_input_key_config()
As there are other bitmap-based config properties that need to be dealt in a
similar fashion as VIRTIO_INPUT_CFG_EV_BITS, generalize the function to
receive select and subsel as arguments, and rename it to
virtio_input_extend_config()
Signed-off-by: Sergio Lopez
---
hw/input/virtio-input-hid.c | 38 -
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c
index a7a244a95d..d28dab69ba 100644
--- a/hw/input/virtio-input-hid.c
+++ b/hw/input/virtio-input-hid.c
@@ -44,30 +44,31 @@ static const unsigned short axismap_abs[INPUT_AXIS__MAX] = {
/* - */
-static void virtio_input_key_config(VirtIOInput *vinput,
-const unsigned short *keymap,
-size_t mapsize)
+static void virtio_input_extend_config(VirtIOInput *vinput,
+ const unsigned short *map,
+ size_t mapsize,
+ uint8_t select, uint8_t subsel)
{
-virtio_input_config keys;
+virtio_input_config ext;
int i, bit, byte, bmax = 0;
-memset(, 0, sizeof(keys));
+memset(, 0, sizeof(ext));
for (i = 0; i < mapsize; i++) {
-bit = keymap[i];
+bit = map[i];
if (!bit) {
continue;
}
byte = bit / 8;
bit = bit % 8;
-keys.u.bitmap[byte] |= (1 << bit);
+ext.u.bitmap[byte] |= (1 << bit);
if (bmax < byte+1) {
bmax = byte+1;
}
}
-keys.select = VIRTIO_INPUT_CFG_EV_BITS;
-keys.subsel = EV_KEY;
-keys.size = bmax;
-virtio_input_add_config(vinput, );
+ext.select = select;
+ext.subsel = subsel;
+ext.size = bmax;
+virtio_input_add_config(vinput, );
}
static void virtio_input_handle_event(DeviceState *dev, QemuConsole *src,
@@ -281,8 +282,9 @@ static void virtio_keyboard_init(Object *obj)
vhid->handler = _keyboard_handler;
virtio_input_init_config(vinput, virtio_keyboard_config);
-virtio_input_key_config(vinput, qemu_input_map_qcode_to_linux,
-qemu_input_map_qcode_to_linux_len);
+virtio_input_extend_config(vinput, qemu_input_map_qcode_to_linux,
+ qemu_input_map_qcode_to_linux_len,
+ VIRTIO_INPUT_CFG_EV_BITS, EV_KEY);
}
static const TypeInfo virtio_keyboard_info = {
@@ -373,8 +375,9 @@ static void virtio_mouse_init(Object *obj)
virtio_input_init_config(vinput, vhid->wheel_axis
? virtio_mouse_config_v2
: virtio_mouse_config_v1);
-virtio_input_key_config(vinput, keymap_button,
-ARRAY_SIZE(keymap_button));
+virtio_input_extend_config(vinput, keymap_button,
+ ARRAY_SIZE(keymap_button),
+ VIRTIO_INPUT_CFG_EV_BITS, EV_KEY);
}
static const TypeInfo virtio_mouse_info = {
@@ -497,8 +500,9 @@ static void virtio_tablet_init(Object *obj)
virtio_input_init_config(vinput, vhid->wheel_axis
? virtio_tablet_config_v2
: virtio_tablet_config_v1);
-virtio_input_key_config(vinput, keymap_button,
-ARRAY_SIZE(keymap_button));
+virtio_input_extend_config(vinput, keymap_button,
+ ARRAY_SIZE(keymap_button),
+ VIRTIO_INPUT_CFG_EV_BITS, EV_KEY);
}
static const TypeInfo virtio_tablet_info = {
--
2.38.1
[PATCH 2/4] virtio-input: add a virtio-mulitouch device
Add a virtio-multitouch device to the family of devices emulated by
virtio-input implementing the Multi-touch protocol as descripted here:
https://www.kernel.org/doc/html/latest/input/multi-touch-protocol.html?highlight=multi+touch
This patch just add the device itself, without connecting it to any
backends. The following patches will add helpers in "ui" and will enable
the GTK3 backend to transpose multi-touch events from the host to the
guest.
Signed-off-by: Sergio Lopez
---
hw/input/virtio-input-hid.c | 123 ++-
hw/virtio/virtio-input-pci.c | 25 ++-
include/hw/virtio/virtio-input.h | 9 ++-
include/ui/input.h | 3 +
qapi/ui.json | 45 ++-
replay/replay-input.c| 18 +
ui/input.c | 6 ++
ui/trace-events | 1 +
8 files changed, 216 insertions(+), 14 deletions(-)
diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c
index d28dab69ba..34109873ac 100644
--- a/hw/input/virtio-input-hid.c
+++ b/hw/input/virtio-input-hid.c
@@ -16,9 +16,11 @@
#include "standard-headers/linux/input.h"
-#define VIRTIO_ID_NAME_KEYBOARD "QEMU Virtio Keyboard"
-#define VIRTIO_ID_NAME_MOUSE"QEMU Virtio Mouse"
-#define VIRTIO_ID_NAME_TABLET "QEMU Virtio Tablet"
+#define VIRTIO_ID_NAME_KEYBOARD "QEMU Virtio Keyboard"
+#define VIRTIO_ID_NAME_MOUSE"QEMU Virtio Mouse"
+#define VIRTIO_ID_NAME_TABLET "QEMU Virtio Tablet"
+#define VIRTIO_ID_NAME_MULTITOUCH "QEMU Virtio Multitouch"
+#define VIRTIO_ID_SERIAL_MULTITOUCH "virtio-touchscreen-0"
/* - */
@@ -30,6 +32,7 @@ static const unsigned short keymap_button[INPUT_BUTTON__MAX]
= {
[INPUT_BUTTON_WHEEL_DOWN]= BTN_GEAR_DOWN,
[INPUT_BUTTON_SIDE] = BTN_SIDE,
[INPUT_BUTTON_EXTRA] = BTN_EXTRA,
+[INPUT_BUTTON_TOUCH] = BTN_TOUCH,
};
static const unsigned short axismap_rel[INPUT_AXIS__MAX] = {
@@ -42,6 +45,11 @@ static const unsigned short axismap_abs[INPUT_AXIS__MAX] = {
[INPUT_AXIS_Y] = ABS_Y,
};
+static const unsigned short axismap_tch[INPUT_AXIS__MAX] = {
+[INPUT_AXIS_X] = ABS_MT_POSITION_X,
+[INPUT_AXIS_Y] = ABS_MT_POSITION_Y,
+};
+
/* - */
static void virtio_input_extend_config(VirtIOInput *vinput,
@@ -81,6 +89,7 @@ static void virtio_input_handle_event(DeviceState *dev,
QemuConsole *src,
InputKeyEvent *key;
InputMoveEvent *move;
InputBtnEvent *btn;
+InputMultitouchEvent *mtt;
switch (evt->type) {
case INPUT_EVENT_KIND_KEY:
@@ -137,6 +146,24 @@ static void virtio_input_handle_event(DeviceState *dev,
QemuConsole *src,
event.value = cpu_to_le32(move->value);
virtio_input_send(vinput, );
break;
+case INPUT_EVENT_KIND_MTT:
+mtt = evt->u.mtt.data;
+if (mtt->type == INPUT_MULTITOUCH_TYPE_DATA) {
+event.type = cpu_to_le16(EV_ABS);
+event.code = cpu_to_le16(axismap_tch[mtt->axis]);
+event.value = cpu_to_le32(mtt->value);
+virtio_input_send(vinput, );
+} else {
+event.type = cpu_to_le16(EV_ABS);
+event.code = cpu_to_le16(ABS_MT_SLOT);
+event.value = cpu_to_le32(mtt->slot);
+virtio_input_send(vinput, );
+event.type = cpu_to_le16(EV_ABS);
+event.code = cpu_to_le16(ABS_MT_TRACKING_ID);
+event.value = cpu_to_le32(mtt->tracking_id);
+virtio_input_send(vinput, );
+}
+break;
default:
/* keep gcc happy */
break;
@@ -515,12 +542,102 @@ static const TypeInfo virtio_tablet_info = {
/* - */
+static QemuInputHandler virtio_multitouch_handler = {
+.name = VIRTIO_ID_NAME_MULTITOUCH,
+.mask = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_MTT,
+.event = virtio_input_handle_event,
+.sync = virtio_input_handle_sync,
+};
+
+static struct virtio_input_config virtio_multitouch_config[] = {
+{
+.select= VIRTIO_INPUT_CFG_ID_NAME,
+.size = sizeof(VIRTIO_ID_NAME_MULTITOUCH),
+.u.string = VIRTIO_ID_NAME_MULTITOUCH,
+},{
+.select= VIRTIO_INPUT_CFG_ID_SERIAL,
+.size = sizeof(VIRTIO_ID_SERIAL_MULTITOUCH),
+.u.string = VIRTIO_ID_SERIAL_MULTITOUCH,
+},{
+.select= VIRTIO_INPUT_CFG_ID_DEVIDS,
+.size = sizeof(struct virtio_input_devids),
+.u.ids = {
+.bustype = const_le16(BUS_VIRTUAL),
+.vendor = const_le16(0x0627), /* same we use for usb hid devices
*/
+.product = const_le16(0x0003),
+.version = const_le16(0x0001),
+},
+},{
+.select
[PATCH 0/4] Implement virtio-multitouch and enable GTK3 to use it
This series adds a virtio-multitouch device to the family of devices emulated by virtio-input implementing the Multi-touch protocol as descripted here: https://www.kernel.org/doc/html/latest/input/multi-touch-protocol.html?highlight=multi+touch It also extends the GTK UI backend to be able to receive multi-touch events and transpose them to a guest, so the latter can recognize them as gestures when appropriate. An example of this in action can be seen here: https://fosstodon.org/@slp/109545849296546767 Sergio Lopez (4): virtio-input: generalize virtio_input_key_config() virtio-input: add a virtio-mulitouch device ui: add helpers for virtio-multitouch events ui/gtk: enable backend to send multi-touch events hw/input/virtio-input-hid.c | 161 +++ hw/virtio/virtio-input-pci.c | 25 - include/hw/virtio/virtio-input.h | 9 +- include/ui/input.h | 8 ++ qapi/ui.json | 45 - replay/replay-input.c| 18 ui/gtk.c | 84 ui/input.c | 42 ui/trace-events | 1 + 9 files changed, 362 insertions(+), 31 deletions(-) -- 2.38.1
Re: [PATCH v1 2/2] hw: allwinner-i2c: Fix TWI_CNTR_INT_FLAG
Hi, Yes, that would explain why this happened. On Sat, Feb 18, 2023 at 3:13 AM qianfan wrote: > > > > 在 2023/2/18 0:54, Strahinja Jankovic 写道: > > Hi, > > > > I tried running Avocado tests for cubieboard with following command: > > > > ARMBIAN_ARTIFACTS_CACHED=yes AVOCADO_ALLOW_LARGE_STORAGE=yes avocado > > --show=app,console run-t machine:cubieboard > > tests/avocado/boot_linux_console.py > > > > Without this patch all tests pass: > > RESULTS: PASS 3 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 > > | CANCEL 0 > > JOB TIME : 53.15 s > > > > However, if I apply this patch, all tests fail. This is part of the > > log that captures the failure: > > > > axp20x-i2c 1-0034: AXP20x variant AXP209 found > > console: random: crng init done > > console: irq 43: nobody cared (try booting with the "irqpoll" option) > > console: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.16-sunxi #21.02.2 > > console: Hardware name: Allwinner sun4i/sun5i Families > > console: [] (unwind_backtrace) from [] > > (show_stack+0x11/0x14) > > console: [] (show_stack) from [] (dump_stack+0x77/0x84) > > console: [] (dump_stack) from [] > > (__report_bad_irq+0x37/0x94) > > console: [] (__report_bad_irq) from [] > > (note_interrupt+0xfb/0x1f4) > > console: [] (note_interrupt) from [] > > (handle_irq_event_percpu+0x4f/0x54) > > console: [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x39/0x50) > > console: [] (handle_irq_event) from [] > > (handle_fasteoi_irq+0x67/0xbc) > > console: [] (handle_fasteoi_irq) from [] > > (generic_handle_irq+0x29/0x34) > > console: [] (generic_handle_irq) from [] > > (__handle_domain_irq+0x43/0x84) > > console: [] (__handle_domain_irq) from [] > > (sun4i_handle_irq+0x3b/0x4c) > > console: [] (sun4i_handle_irq) from [] > > (__irq_svc+0x65/0x94) > > console: Exception stack(0xc1517950 to 0xc1517998) > > console: 7940: c1701ca0 6153 > > 00e4 0001 > > console: 7960: c1701c40 0002 6153 c1517a1c c1701ca0 > > c0f03d00 fffede04 > > console: 7980: c15179a0 c075ebb7 c09785d4 0173 > > console: [] (__irq_svc) from [] > > (_raw_spin_unlock_irqrestore+0x1c/0x20) > > console: [] (_raw_spin_unlock_irqrestore) from [] > > (mv64xxx_i2c_xfer+0x5b/0x13c) > > console: [] (mv64xxx_i2c_xfer) from [] > > (__i2c_transfer+0x145/0x4c0) > > console: [] (__i2c_transfer) from [] > > (i2c_transfer+0x5b/0xbc) > > console: [] (i2c_transfer) from [] > > (regmap_i2c_read+0x49/0x68) > > console: [] (regmap_i2c_read) from [] > > (_regmap_raw_read+0x99/0x1d8) > > console: [] (_regmap_raw_read) from [] > > (_regmap_bus_read+0x29/0x40) > > console: [] (_regmap_bus_read) from [] > > (_regmap_read+0x3d/0xe8) > > console: [] (_regmap_read) from [] > > (_regmap_update_bits+0x75/0xb0) > > console: [] (_regmap_update_bits) from [] > > (regmap_update_bits_base+0x39/0x50) > > console: [] (regmap_update_bits_base) from [] > > (regmap_irq_update_bits+0x2f/0x34) > > console: [] (regmap_irq_update_bits) from [] > > (regmap_add_irq_chip_fwnode+0x56f/0x72c) > > console: [] (regmap_add_irq_chip_fwnode) from [] > > (regmap_add_irq_chip+0x2f/0x34) > > console: [] (regmap_add_irq_chip) from [] > > (axp20x_device_probe+0x3f/0x368) > > console: [] (axp20x_device_probe) from [] > > (i2c_device_probe+0x1d3/0x1e4) > > console: [] (i2c_device_probe) from [] > > (really_probe+0xb7/0x378) > > console: [] (really_probe) from [] > > (driver_probe_device+0xa9/0x16c) > > console: [] (driver_probe_device) from [] > > (bus_for_each_drv+0x4d/0x78) > > console: [] (bus_for_each_drv) from [] > > (__device_attach+0x8f/0xf0) > > console: [] (__device_attach) from [] > > (bus_probe_device+0x5b/0x60) > > console: [] (bus_probe_device) from [] > > (device_add+0x2e7/0x564) > > console: [] (device_add) from [] > > (i2c_new_client_device+0xdf/0x1bc) > > console: [] (i2c_new_client_device) from [] > > (of_i2c_register_device+0x71/0x90) > > console: [] (of_i2c_register_device) from [] > > (of_i2c_register_devices+0x59/0xc4) > > console: [] (of_i2c_register_devices) from [] > > (i2c_register_adapter+0x195/0x53c) > > console: [] (i2c_register_adapter) from [] > > (mv64xxx_i2c_probe+0x199/0x440) > > console: [] (mv64xxx_i2c_probe) from [] > > (platform_drv_probe+0x33/0x68) > > console: [] (platform_drv_probe) from [] > > (really_probe+0xb7/0x378) > > console: [] (really_probe) from [] > > (driver_probe_device+0xa9/0x16c) > > console: [] (driver_probe_device) from [] > > (device_driver_attach+0x3d/0x40) > > console: [] (device_driver_attach) from [] > > (__driver_attach+0x5d/0xe0) > > console: [] (__driver_attach) from [] > > (bus_for_each_dev+0x41/0x68) > > console: [] (bus_for_each_dev) from [] > > (bus_add_driver+0xe7/0x154) > > console: [] (bus_add_driver) from [] > > (driver_register+0x39/0xa0) > > console: [] (driver_register) from [] > > (do_one_initcall+0x39/0x1b0) > > console: [] (do_one_initcall) from [] > > (kernel_init_freeable+0x1c1/0x20c) > > console: []
Re: [PATCH v6 2/4] target/riscv: implement Zicboz extension
On 2023/2/18 04:34, Daniel Henrique Barboza wrote:
From: Christoph Muellner
The RISC-V base cache management operation (CBO) ISA extension has been
ratified. It defines three extensions: Cache-Block Management, Cache-Block
Prefetch and Cache-Block Zero. More information about the spec can be
found at [1].
Let's start by implementing the Cache-Block Zero extension, Zicboz. It
uses the cbo.zero instruction that, as with all CBO instructions that
will be added later, needs to be implemented in an overlap group with
the LQ instruction due to overlapping patterns.
cbo.zero throws a Illegal Instruction/Virtual Instruction exception
depending on CSR state. This is also the case for the remaining cbo
instructions we're going to add next, so create a check_zicbo_envcfg()
that will be used by all Zicbo[mz] instructions.
[1]
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf
Co-developed-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 4 ++
target/riscv/cpu.h | 2 +
target/riscv/helper.h | 3 ++
target/riscv/insn32.decode | 10 +++-
target/riscv/insn_trans/trans_rvzicbo.c.inc | 30 +++
target/riscv/op_helper.c| 55 +
target/riscv/translate.c| 1 +
7 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 93b52b826c..7dd37de7f9 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -74,6 +74,7 @@ struct isa_ext_data {
static const struct isa_ext_data isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(h, false, PRIV_VERSION_1_12_0, ext_h),
ISA_EXT_DATA_ENTRY(v, false, PRIV_VERSION_1_10_0, ext_v),
+ISA_EXT_DATA_ENTRY(zicboz, true, PRIV_VERSION_1_12_0, ext_icboz),
ISA_EXT_DATA_ENTRY(zicsr, true, PRIV_VERSION_1_10_0, ext_icsr),
ISA_EXT_DATA_ENTRY(zifencei, true, PRIV_VERSION_1_10_0, ext_ifencei),
ISA_EXT_DATA_ENTRY(zihintpause, true, PRIV_VERSION_1_10_0,
ext_zihintpause),
@@ -1126,6 +1127,9 @@ static Property riscv_cpu_extensions[] = {
DEFINE_PROP_BOOL("zhinx", RISCVCPU, cfg.ext_zhinx, false),
DEFINE_PROP_BOOL("zhinxmin", RISCVCPU, cfg.ext_zhinxmin, false),
+DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),
+DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
+
DEFINE_PROP_BOOL("zmmul", RISCVCPU, cfg.ext_zmmul, false),
/* Vendor-specific custom extensions */
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 7128438d8e..6b4c714d3a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -447,6 +447,7 @@ struct RISCVCPUConfig {
bool ext_zkt;
bool ext_ifencei;
bool ext_icsr;
+bool ext_icboz;
bool ext_zihintpause;
bool ext_smstateen;
bool ext_sstc;
@@ -494,6 +495,7 @@ struct RISCVCPUConfig {
char *vext_spec;
uint16_t vlen;
uint16_t elen;
+uint16_t cboz_blocksize;
bool mmu;
bool pmp;
bool epmp;
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 0497370afd..ce165821b8 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -97,6 +97,9 @@ DEF_HELPER_FLAGS_2(fcvt_h_l, TCG_CALL_NO_RWG, i64, env, tl)
DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
DEF_HELPER_FLAGS_2(fclass_h, TCG_CALL_NO_RWG_SE, tl, env, i64)
+/* Cache-block operations */
+DEF_HELPER_2(cbo_zero, void, env, tl)
+
/* Special functions */
DEF_HELPER_2(csrr, tl, env, int)
DEF_HELPER_3(csrw, void, env, int, tl)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index b7e7613ea2..3985bc703f 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -179,7 +179,15 @@ sraw 010 . . 101 . 0111011 @r
# *** RV128I Base Instruction Set (in addition to RV64I) ***
ldu . 111 . 011 @i
-lq . 010 . 000 @i
+{
+ [
+# *** RV32 Zicboz Standard Extension ***
+cbo_zero 000 00100 . 010 0 000 @sfence_vm
+ ]
+
+ # *** RVI128 lq ***
+ lq . 010 . 000 @i
+}
sq . 100 . 0100011 @s
addid . 000 . 1011011 @i
sllid00 .. . 001 . 1011011 @sh6
diff --git a/target/riscv/insn_trans/trans_rvzicbo.c.inc
b/target/riscv/insn_trans/trans_rvzicbo.c.inc
new file mode 100644
index 00..feabc28342
--- /dev/null
+++ b/target/riscv/insn_trans/trans_rvzicbo.c.inc
@@ -0,0 +1,30 @@
+/*
+ * RISC-V translation routines for the RISC-V CBO Extension.
+ *
+ * Copyright (c) 2021 Philipp Tomsich, philipp.toms...@vrull.eu
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the
Re: [PATCH] [PATCH] disas/riscv Fix ctzw disassemble
On 2023/2/18 00:10, Ivan Klokov wrote:
Due to typo in opcode list, ctzw is disassembled as clzw instruction.
Fixes: 02c1b569a15b ("disas/riscv: Add Zb[abcs] instructions")
Signed-off-by: Ivan Klokov
---
v2:
- added fixes line
Reviewed-by: Weiwei Li
Weiwei Li
---
disas/riscv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disas/riscv.c b/disas/riscv.c
index ddda687c13..544558 100644
--- a/disas/riscv.c
+++ b/disas/riscv.c
@@ -1645,7 +1645,7 @@ const rv_opcode_data opcode_data[] = {
{ "max", rv_codec_r, rv_fmt_rd_rs1_rs2, NULL, 0, 0, 0 },
{ "maxu", rv_codec_r, rv_fmt_rd_rs1_rs2, NULL, 0, 0, 0 },
{ "clzw", rv_codec_r, rv_fmt_rd_rs1, NULL, 0, 0, 0 },
-{ "clzw", rv_codec_r, rv_fmt_rd_rs1, NULL, 0, 0, 0 },
+{ "ctzw", rv_codec_r, rv_fmt_rd_rs1, NULL, 0, 0, 0 },
{ "cpopw", rv_codec_r, rv_fmt_rd_rs1, NULL, 0, 0, 0 },
{ "slli.uw", rv_codec_i_sh5, rv_fmt_rd_rs1_imm, NULL, 0, 0, 0 },
{ "add.uw", rv_codec_r, rv_fmt_rd_rs1_rs2, NULL, 0, 0, 0 },
Re: [PATCH v3 07/10] qapi: implement conditional command arguments
Hi Markus
On Fri, Feb 17, 2023 at 12:28 PM Markus Armbruster
wrote:
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > The generated code doesn't quite handle the conditional arguments.
> > For example, 'bar' in 'test-if-cmd' is not correctly surrounded by #if
> > conditions. See generated code in qmp_marshal_test_if_cmd().
> >
> > Note that if there are multiple optional arguments at the last position,
> > there might be compilation issues due to extra comas. I left an assert
> > and FIXME for later.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > scripts/qapi/commands.py| 4
> > scripts/qapi/gen.py | 19 ++-
> > scripts/qapi/visit.py | 2 ++
> > tests/qapi-schema/qapi-schema-test.json | 3 ++-
> > 4 files changed, 22 insertions(+), 6 deletions(-)
> >
> > diff --git a/scripts/qapi/commands.py b/scripts/qapi/commands.py
> > index 79c5e5c3a9..07997d1586 100644
> > --- a/scripts/qapi/commands.py
> > +++ b/scripts/qapi/commands.py
> > @@ -64,9 +64,13 @@ def gen_call(name: str,
> > elif arg_type:
> > assert not arg_type.variants
> > for memb in arg_type.members:
> > +if memb.ifcond.is_present():
> > +argstr += '\n' + memb.ifcond.gen_if()
> > if memb.need_has():
> > argstr += 'arg.has_%s, ' % c_name(memb.name)
> > argstr += 'arg.%s, ' % c_name(memb.name)
> > +if memb.ifcond.is_present():
> > +argstr += '\n' + memb.ifcond.gen_endif()
> >
> > lhs = ''
> > if ret_type:
>
> @argstr is emitted further down:
>
>%(lhs)sqmp_%(name)s(%(args)s);
>''',
> name=name, args=argstr, lhs=lhs)
>
>ret += mcgen('''
>if (err) {
>''')
>
> Before the patch, @argstr contains no newlines. Works.
>
> After the patch, it may contain newlines, and if it does, intentation is
> messed up. For instance, in the code generated for
> qapi-schema-test.json:
>
> retval = qmp_test_if_cmd(arg.foo,
> #if defined(TEST_IF_CMD_BAR)
> arg.bar,
> #endif /* defined(TEST_IF_CMD_BAR) */
> );
>
> Strings interpolated into the mcgen() argument should not contain
> newlines. I'm afraid you have to rewrite the code emitting the call.
>
Why it should not contain newlines?
What are you asking exactly? that the caller be changed? (this does not
work well if there are multiple optional arguments..)
#if defined(TEST_IF_CMD_BAR)
retval = qmp_test_if_cmd(arg.foo, arg.bar, );
#else
retval = qmp_test_if_cmd(arg.foo, );
#endif /* defined(TEST_IF_CMD_BAR) */
>
> > diff --git a/scripts/qapi/gen.py b/scripts/qapi/gen.py
> > index b5a8d03e8e..ba57e72c9b 100644
> > --- a/scripts/qapi/gen.py
> > +++ b/scripts/qapi/gen.py
> > @@ -111,22 +111,31 @@ def build_params(arg_type:
> Optional[QAPISchemaObjectType],
> > boxed: bool,
> > extra: Optional[str] = None) -> str:
> > ret = ''
> > -sep = ''
> > if boxed:
> > assert arg_type
> > ret += '%s arg' % arg_type.c_param_type()
> > -sep = ', '
> > +if extra:
> > +ret += ', '
> > elif arg_type:
> > assert not arg_type.variants
> > +n = 0
> > for memb in arg_type.members:
> > -ret += sep
> > -sep = ', '
> > +n += 1
> > +if memb.ifcond.is_present():
> > +ret += '\n' + memb.ifcond.gen_if()
> > if memb.need_has():
> > ret += 'bool has_%s, ' % c_name(memb.name)
> > ret += '%s %s' % (memb.type.c_param_type(),
> >c_name(memb.name))
> > +if extra or n != len(arg_type.members):
> > +ret += ', '
> > +else:
> > +# FIXME: optional last argument may break compilation
> > +assert not memb.ifcond.is_present()
>
> Does the assertion guard against the C compilation failure?
>
Yes
>
> Is it possible to write schema code that triggers it?
>
Yes, the one we have for TEST_IF_EVENT for example:
{ 'event': 'TEST_IF_EVENT',
'data': { 'foo': 'TestIfStruct',
'bar': { 'type': ['TestIfEnum'], 'if': 'TEST_IF_EVT_BAR' } },
produces:
void qapi_event_send_test_if_event(TestIfStruct *foo,
#if defined(TEST_IF_EVT_BAR)
TestIfEnumList *bar,
#endif /* defined(TEST_IF_EVT_BAR) */
);
Which will fail to compile if TEST_IF_EVT_BAR is undefined.
So I would rather assert that we don't introduce such a schema, until we
fix the code generator. Or we acknowledge the limitation, and treat it as a
schema error. Other ideas?
> > +if memb.ifcond.is_present():
> > +ret += '\n' + memb.ifcond.gen_endif()
> > if extra:
> > -ret += sep + extra
> > +ret += extra
> > return ret if ret else 'void'
> >
> >
>
> Same newline issue as in
Re: [PATCH v3 08/10] qmp: teach 'getfd' to import sockets on win32
Hi Markus
On Fri, Feb 17, 2023 at 1:49 PM Markus Armbruster wrote:
>
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > A process with enough capabilities can duplicate a socket to QEMU.
> > Modify 'getfd' to import it and add it to the monitor fd list, so it can
> > be later used by other commands.
> >
> > Note that we actually store the SOCKET in the FD list, appropriate care
> > must now be taken to use the correct socket functions (similar approach
> > is taken by our io/ code and in glib, this is internal and shouldn't
> > affect the QEMU/QMP users)
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > qapi/misc.json | 16 --
> > monitor/fds.c | 79 --
> > monitor/hmp-cmds.c | 6 +++-
> > 3 files changed, 81 insertions(+), 20 deletions(-)
> >
> > diff --git a/qapi/misc.json b/qapi/misc.json
> > index 27ef5a2b20..cd36d8befb 100644
> > --- a/qapi/misc.json
> > +++ b/qapi/misc.json
> > @@ -249,10 +249,18 @@
> > ##
> > # @getfd:
> > #
> > -# Receive a file descriptor via SCM rights and assign it a name
> > +# On UNIX, receive a file descriptor via SCM rights and assign it a name.
> > +#
> > +# On Windows, (where ancillary socket fd-passing isn't an option yet), add
> > a
> > +# socket that was duplicated to QEMU process with WSADuplicateSocketW() via
> > +# WSASocket() & WSAPROTOCOL_INFOW structure and assign it a name. A SOCKET
> > is
> > +# considered as a kind of "file descriptor" in QMP context, for historical
> > +# reasons and simplicity. QEMU takes care to use socket functions
> > appropriately.
>
> The Windows part explains things in terms of the C socket API. Less
> than ideal for the QEMU QMP Reference Manual, isn't it? I don't know
> nearly enough about this stuff to suggest concrete improvements...
We don't have to, after all we don't explain how to use sendmsg/cmsg
stuff to pass FDs.
I will drop the part about "A SOCKET is considered as a kind of "file
descriptor" in QMP context", after we get "[PATCH 0/4] win32: do not
mix SOCKET and fd space"
(https://patchew.org/QEMU/20230212204942.1905959-1-marcandre.lur...@redhat.com/)
merged.
>
> What does this command do under Windows before this patch? Fail always?
Without ancillary data support on Windows, you can't make it work.
>
> Wrap your lines a bit earlier, please.
>
> > #
> > # @fdname: file descriptor name
> > #
> > +# @wsa-info: a WSAPROTOCOL_INFOW structure (encoded in base64). Since 8.0.
> > +#
>
> No way around passing a binary blob?
WSAPROTOCOL_INFOW is a fairly big structure, with private/reserved fields,
it contains another structure (WSAPROTOCOLCHAIN), has fixed-length arrays,
GUID, and utf16 string.
QAPI'fying that structure back and forth would be tedious and
error-prone. Better to treat it as an opaque blob imho.
>
> > # Returns: Nothing on success
> > #
> > # Since: 0.14
> > @@ -270,7 +278,11 @@
> > # <- { "return": {} }
> > #
> > ##
> > -{ 'command': 'getfd', 'data': {'fdname': 'str'} }
> > +{ 'command': 'getfd', 'data': {
> > +'fdname': 'str',
> > +'*wsa-info': {'type': 'str', 'if': 'CONFIG_WIN32'}
> > + }
> > +}
>
> What happens when QEMU runs on a Windows host and the client doesn't
> pass @wsa-info?
It attempts to get the fd from the last recv, but it will fail on
Windows, this is not available.
--
Marc-André Lureau
Re: [PATCH v5 3/4] target/riscv: implement Zicbom extension
On 2/15/23 19:18, Richard Henderson wrote:
On 2/15/23 12:13, Richard Henderson wrote:
ret = probe_access_flags(env, address, MMU_DATA_LOAD, mmu_idx, true,
, ra);
if (ret != TLB_INVALID_MASK) {
/* Success: readable */
return;
}
...
At which point the new probe_acccess_range_flags is not needed.
Oh, I get it, the range is required for PMP, for sub-page range checks.
I wonder how tedious it would be to adjust all callers, rather than inventing
yet another interface...
I took a look at the amount of tediousness involved. It's feasible to do if we
want to add a 'size' param in probe_access_flags() - existing callers would
use size = 0, RISC-V can use the appropriate size.
I'll see if I can pull it off and send it as an alternative in the next
version.
Thanks,
Daniel
r~
Re: [PATCH v6 2/4] target/riscv: implement Zicboz extension
On 2/18/23 00:44, Richard Henderson wrote:
On 2/17/23 10:34, Daniel Henrique Barboza wrote:
+void helper_cbo_zero(CPURISCVState *env, target_ulong address)
+{
+ RISCVCPU *cpu = env_archcpu(env);
+ uintptr_t ra = GETPC();
+ uint16_t cbozlen;
+ void *mem;
+
+ check_zicbo_envcfg(env, MENVCFG_CBZE, ra);
+
+ /* Get the size of the cache block for zero instructions. */
+ cbozlen = cpu->cfg.cboz_blocksize;
+
+ /* Mask off low-bits to align-down to the cache-block. */
+ address &= ~(cbozlen - 1);
+
+ mem = tlb_vaddr_to_host(env, address, MMU_DATA_STORE,
+ cpu_mmu_index(env, false));
+
+ if (likely(mem)) {
+ /* Zero the block */
+ memset(mem, 0, cbozlen);
+ }
+}
Not correct. This fails to zero the block at all under a number of conditions.
Ops. The 'else' conditional in which we would zero the mem in case it's an I/O
region got lost in the middle of rebasing it seems
By the way, looking at the lack of any probing in this particular function and
at
the probe_writes() that ARM does, I read the spec again. A paragraph in 2.5.2
says:
"A cache-block zero instruction is permitted to access the specified cache
block whenever
a store instruction is permitted to access the corresponding physical addresses
and when
the PMAs indicate that cache-block zero instructions are a supported access
type. If access
to the cache block is not permitted, a cache-block zero instruction raises a
store page fault
or store guest-page fault exception if address translation does not permit
write access or
raises a store access fault exception otherwise. During address translation,
the instruction
also checks the accessed and dirty bits and may either raise an exception or
set the bits as
required."
PMA (Physical Memory Access) doesn't seem to be implemented in RISC-V, or at
the very least
it's not using the PMA acronym, so let's skip that for now. I'll add a comment
mentioning
it in the code mentioning that PMA for I/O should be checked and we're not
doing it.
But PMA aside, we have wording and conditionals that resembles the cache-block
management
permissions and so on, with the exception that we're not caring about LOAD
access this time
around. So I guess we'll also need here something like what
check_zicbom_access() is doing
in the next patch.
Thanks,
Daniel
Please have a closer look at the feedback on v5.
r~
Re: [RFC PATCH] docs: build-platforms: refine requirements on Python build dependencies
Daniel P. Berrangé writes: > On Fri, Feb 17, 2023 at 01:41:50PM +0100, Paolo Bonzini wrote: [...] >> This proposed update to the support policy chooses the last of these >> possibilities. It does by modifying two aspects of the support policy: >> >> * it introduces different support periods for *native* vs. *non-native* >> dependencies. Non-native dependencies are currently Python ones only, >> and for simplicity the policy only mentions Python; however, the concept >> generalizes to other languages with a well-known upstream package >> manager, that users of older distributions can fetch dependencies from; > > I guess this would mean its applicable to perl/ruby/etc, but really > we should be exclusively using Python for our scripting needs, except > for legacy stuff we already have. So in practice non-native == python. > > Potentially if we want to use Rust, we'd want vendoring of deps needed > by Rust code, and that's native deps arguably, rather than non-native. > > Still I think it is unlikely we would replace existing working code in > qemu.git with a rust impl, while discarding the original impl. More > likely we'd have a Rust impl in parallel, or use Rust only for a brand > new feature, where we don't need to support all possible old platforms. I'm not sure. However, there's no real need to anticipate right now how we will use Rust; we can update our support policy when we know. >> * it limits the support period for non-native dependencies to a fixed >> amount of 4 years. This is intended to be close to the Python 5-year >> lifecycle while accounting for the time between a distro's feature freeze >> and the day it's released. This limit applies to all distro versions, >> not just the previous one, in order to cater for the delay of SLE 16. >> >> The 4 year cutoff in practice means that QEMU will be able to drop Python >> 3.6 support for QEMU 7.1 (RHEL8 becomes 4 year old next May, while SLE >> is already over the threshold). > > So the 4 year timeframe enables us to move off 3.6, but it is still > potentially limiting. > > That doesn't explicitly allow for the case where we decide we want > to increae min version of flake8/pylint/mypy to one that is merly > 1 year old. As noted, covering multiple versions of these linting > tools is a burden, as the issues reported from new versions are > not always a superset of the old version. So it is somewhat > desirable to fixate on a specific release, or a narrow range of > releases. Concur. > I guess we can argue that any optional build time components that > only affect testing don't need to be constrained by our platform > policy in the first, since they are optional and don't affect the > ability to build QEMU. Still if I'm a distro maintainer, and > backporting patches I like to run all static analysis tools to > catch silly python mistake that happen when cherry-picking. Yes, but you want to run the static analysis tools required by the QEMU you're backporting to, not the one you're backporting from (unless you're backporting the patches needed to make the newer linters happy, and then bump the dependencies). > Equally if I'm a contributor working on QEMU I would like to > run all the static linting tests available. This one is valid. Still, it's a "want", not a "must have". If it was a hard "must have", then CentOS 8 support would be in trouble: no mypy out of the box, as far as I can tell. We can rely on CI to find the lint. Delays the feedback, which not ideal, but also not unlike how we use CI to keep the build working on all hosts (because not every developer has access to all hosts) and in a multitude of configurations (requiring all developers to test all configurations at all times would be impractical, so we don't). Let's consider the special case mypy. Right now, you have to run it manually, but John has been working on integrating it into the build process. Now compare two extremes: (A) Commit to keeping mypy happy for all versions of mypy provided by any supported build host The build runs mypy if the build host provides it. Immediate feedback then, but only from a single mypy version. Developers still have to run all the mypy versions somehow, or else punt to maintainers, who may in turn punt to CI. Delayed feedback from all mypy versions but one. We operate with the intersection of mypy features and the union of mypy bugs, which is bound to complicate the typing job, and may well limit typing power. (B) Pick a single mypy version Developers have to run this mypy version, or else punt to maintainers. We'll naturally pick a mypy version the maintainers are happy to run, so no need for them to punt to CI. We can exploit the full typing power of that mypy version. We don't have to work around issues older versions may have. Developers unable to run this mypy version locally get delayed feedback. Affects the intersection of
