Debug exceptions that target AArch32 Hyp mode are reported differently
than on AAarch64. Internally, Qemu uses the AArch64 syndromes. Therefore
such exceptions need to be either converted to a prefetch abort
(breakpoints, vector catch) or a data abort (watchpoints).
Signed-off-by: Jan Klötzke
On Tue, 2024-01-23 at 17:58 +, Peter Maydell wrote:
> On Fri, 19 Jan 2024 at 22:40, Jan Klötzke
> wrote:
>
> > ---
> > target/arm/helper.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/target/arm/helper.c b/t
On 22.01.24 10:50, Alex Bennée wrote:
> Jan Kiszka writes:
>
>> On 19.01.24 12:24, Alex Bennée wrote:
>>> Peter Maydell writes:
>>>
>>>> Convert the musicpal key input device to use
>>>> qemu_add_kbd_event_handler(). This lets us simplify it
ough. I think I haven't run the
whole stuff in a decade or so, had to search for all the pieces first of
all again. The webradio service original behind this stopped their
operations, at least for this device, but manually entered favorits
still work on the real device - I still have one, though that is
starting to get some issues as well.
Thanks,
Jan
Debug exceptions that target AArch32 Hyp mode are reported differently
than on AAarch64. Internally, Qemu uses the AArch64 syndromes. Therefore
such exceptions need to be either converted to a prefetch abort
(breakpoints, vector catch) or a data abort (watchpoints).
Signed-off-by: Jan Klötzke
blocked via", but perhaps
yet better wording can be thought of.
Jan
PS: Personally I'm against such avoiding of certain words. Them being
misused is not really a justification. New wording (perhaps not
specifically here, but considering the underlying wider theme) is going
to be misused as w
Document display::gtk::zoom-to-fit.
info from:
https://superuser.com/questions/1752209/qemu-zoom-to-fit-shortcut-or-cli-switch
Signed-off-by: Jan Kratochvil
diff --git a/qemu-options.hx b/qemu-options.hx
index 88e93c6103..90acb31056 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
On 3/16/23 09:54, Philippe Mathieu-Daudé wrote:
On 16/3/23 00:02, John Snow wrote:
On Wed, Mar 15, 2023 at 5:17 PM Philippe Mathieu-Daudé
wrote:
+Jan
On 22/2/23 15:37, Paolo Bonzini wrote:
From: John Snow
The pipenv tool was nice in theory, but in practice it's just too hard
to update
le_bit) {
> /* don't allow enabling together with other interrupt types */
> int int_type = xen_pcibk_get_interrupt_type(dev);
>
> 8<
>
> Jan, is the above safe? It should prevent clearing MASKALL if INTx isn't
> disabled, unless I mi
On 15.11.2022 12:38, Marek Marczykowski-Górecki wrote:
> On Tue, Nov 15, 2022 at 09:14:07AM +0100, Jan Beulich wrote:
>> On 14.11.2022 20:20, Marek Marczykowski-Górecki wrote:
>>> The /dev/mem is used for two purposes:
>>> - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
>&
en extended to handle
> this case too (as well as other registers that may live on those pages),
> so QEMU handling is not necessary anymore.
Don't you need to check for new enough Xen for both aspects?
Jan
On 11/10/22 20:29, Daniel Henrique Barboza wrote:
On 11/10/22 11:57, Jan Richter wrote:
On 11/10/22 00:26, Philippe Mathieu-Daudé wrote:
On 9/11/22 16:39, Daniel Henrique Barboza wrote:
On 10/27/22 06:01, Daniel P. Berrangé wrote:
On Thu, Oct 27, 2022 at 09:46:29AM +0200, Thomas Huth
llel-tasks
- Jan
That it is so difficult to update Avocado after barely more than
1 year is not exactly a strong vote of confidence in our continued
use of Avocado long term :-(
By the way, Avocado just provided a fix for the problem this patch is
trying
to amend:
https://github.com/avocado
On 17.10.2022 10:12, Arthur Borsboom wrote:
> Xen 4.16.1, 4.16.2 and 4.17.0-rc1 don't build anymore in Arch Linux.
That is, qemu doesn't build. That's something to be taken care of there,
not in Xen, I think.
Jan
> I believe it is caused by the missing function
> bpf_program__set_sock
your thoughts on this
Best regards
Jan Louw
CTO AITechGroup
South Africa
https://aitechgroup.co.za/
On 05.05.22 10:40, Peter Maydell wrote:
> On Sun, 1 May 2022 at 19:07, Jan Kiszka wrote:
>>
>> From: Jan Kiszka
>>
>> The virt machine lacks a watchdog so far while the sbsa-ref has a simple
>> model that is also supported by Linux and even U-Boot. Let's
From: Jan Kiszka
The virt machine lacks a watchdog so far while the sbsa-ref has a simple
model that is also supported by Linux and even U-Boot. Let's take it to
allow, e.g., system integration tests of A/B software update under
watchdog monitoring.
Signed-off-by: Jan Kiszka
an't open /dev/mem: Operation not
> permitted
> [00:04.0] xen_pt_msix_size_init: Error: Internal error: Invalid
> xen_pt_msix_init.
>
> And the kernel reports this:
>
> Jan 27 16:20:53 narvi-sr860v2-bps-sles15sp4b2 kernel: Lockdown:
> qemu-system-i38: /dev/mem,kmem,port is restricte
Break events are currently only handled by chardev/char-serial.c, so we
just ignore errors, which results in no behaviour change for other
chardevs.
Signed-off-by: Jan Luebbe
---
hw/char/pl011.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index
Ah ok, I think this bug can be closed then.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721788
Title:
Failed to get shared "write" lock
** Description changed:
When running 'qemu-img info test.qcow2' while test.qcow2 is currently
used by a Qemu process, I get the error
qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
lock.
-
- Why does displaying information about a disk image need a write lock
On Thu 12-11-20 17:38:36, Maxim Levitsky wrote:
> On Thu, 2020-11-12 at 12:19 +0100, Jan Kara wrote:
> > [added some relevant people and lists to CC]
> >
> > On Wed 11-11-20 17:44:05, Maxim Levitsky wrote:
> > > On Wed, 2020-11-11 at 17:39 +0200, Maxim
On Thu 12-11-20 12:19:51, Jan Kara wrote:
> [added some relevant people and lists to CC]
>
> On Wed 11-11-20 17:44:05, Maxim Levitsky wrote:
> > On Wed, 2020-11-11 at 17:39 +0200, Maxim Levitsky wrote:
> > > clone of "starship_production"
> >
> &
thing happened to the page cache
outside of discarded range (like you describe above), that is a kernel bug
than needs to get fixed. EBUSY should really mean - someone wrote to the
discarded range while discard was running and userspace app has to deal
with that depending on what it aims to do...
Honza
--
Jan Kara
SUSE Labs, CR
On 06.10.20 14:41, Philippe Mathieu-Daudé wrote:
> On 10/6/20 11:44 AM, Alex Bennée wrote:
>>
>> Jan Kiszka writes:
>>
>>> On 05.10.20 22:52, Joseph Myers wrote:
>>>> On Mon, 5 Oct 2020, Alex Bennée wrote:
>>>>
>>>>> Joseph M
ns into
>> contrib/gitdm/group-map-wavecomp.
>>
>> It's really up to you and which corporate entity would like internet
>> bragging points. The only Siemens contributor I could find is Jan Kiszka
>> but he has contributed a fair amount ;-)
>
> Given that the M
On 05.10.20 13:05, Stefano Garzarella wrote:
> On Mon, Oct 05, 2020 at 11:45:41AM +0200, Jan Kiszka wrote:
>> On 05.10.20 11:29, Stefano Garzarella wrote:
>>> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
>>>> On 05.10.20 10:14, Stefano Garzarella wro
On 05.10.20 11:29, Stefano Garzarella wrote:
> On Mon, Oct 05, 2020 at 10:33:30AM +0200, Jan Kiszka wrote:
>> On 05.10.20 10:14, Stefano Garzarella wrote:
>>> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
>>>> On 01.10.20 16:31, Stefano Garzarella wro
On 05.10.20 10:14, Stefano Garzarella wrote:
> On Sun, Oct 04, 2020 at 08:52:37PM +0200, Jan Kiszka wrote:
>> On 01.10.20 16:31, Stefano Garzarella wrote:
>>> Hi,
>>> I had some issues with gdb scripts and kernel modules in Linux 5.9-rc7.
>>>
>>> If
self.loaded_modules.append(module_name)
> else:
>
> I tried several modules and this happens every time after '(gdb) lx-symbols'.
>
> Do you have any hints?
>
I assume you are debugging a kernel inside QEMU/KVM, right? Does it work
without -enabl
We need to specify SDL_WINDOW_OPENGL if we want to create an OpenGL
context on it, i.e. when using '-device virtio-gpu-pci,virgl=on'
Signed-off-by: Jan Henrik Weinstock
---
ui/sdl2.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/ui/sdl2.c b/ui/sdl2.c
index abad7f981e..189d26e2a9
On 27.07.20 15:56, Michael S. Tsirkin wrote:
On Mon, Jul 27, 2020 at 03:39:32PM +0200, Jan Kiszka wrote:
On 27.07.20 15:20, Michael S. Tsirkin wrote:
On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:
Vendor Specific Capability (ID 09h)
This capability must always be present
On 27.07.20 15:20, Michael S. Tsirkin wrote:
On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:
Vendor Specific Capability (ID 09h)
This capability must always be present.
| Offset | Register| Content
hflags2 SVM-only.
Reported-by: Jan Kiszka
Fixes: b16c0e20c742 ("KVM: add support for AMD nested live migration")
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/target/i386/kvm.c b/target/i38
Habkost wrote:
On Wed, Jul 22, 2020 at 08:05:01PM +0200, Jan Kiszka wrote:
On 22.07.20 19:35, Eduardo Habkost wrote:
Hi Jan,
What was the last version where it worked for you? Does using
"-cpu host,-vmx" help?
Yeah, -vmx does indeed help.
I didn't have the time to bisect yet. Jus
On 23.07.20 08:54, Stefan Hajnoczi wrote:
On Fri, Jul 17, 2020 at 06:15:58PM +0200, Jan Kiszka wrote:
On 15.07.20 15:27, Stefan Hajnoczi wrote:
On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:
Thanks for the responses. It would be great to update the spec with
these clarifications
On 22.07.20 19:35, Eduardo Habkost wrote:
Hi Jan,
What was the last version where it worked for you? Does using
"-cpu host,-vmx" help?
Yeah, -vmx does indeed help.
I didn't have the time to bisect yet. Just check my reflog, picked
eb6490f544, and that works.
HTH,
Jan
On W
Hi all,
this locks up the guest:
- qemu-system-x86_64 -enable-kvm -cpu host
- trigger hard reset
Host kernel: 5.7.7.
Host CPU: i7-8850H
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
kend code to be plumbed into both transports. Why shouldn't
work what already works well under Linux with the frontend device
drivers vs. virtio transports?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
On 21.07.20 18:35, Richard Henderson wrote:
When we changed the interface of get_phys_addr_lpae to require
the cacheattr parameter, this spot was missed. The compiler is
unable to detect the use of NULL vs the nonnull attribute here.
Fixes: 7e98e21c098
Reported-by: Jan Kiszka
Signed-off
f4d8cf148e43.
Any ideas?
Jan
[1] https://github.com/siemens/jailhouse-images
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
On 15.07.20 15:27, Stefan Hajnoczi wrote:
On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:
IVSHMEM Device Specification
** NOTE: THIS IS WORK-IN-PROGRESS, NOT YET A STABLE INTERFACE SPECIFICATION! **
Hi Jan,
Thanks for posting this! I have a posted
ommunication between VMs.
>This device already exists but is limited in its current form. The
>"v2" project updates IVSHMEM's capabilities and makes it suitable as
>a VIRTIO transport.
>
>Jan Kiszka is working on this and has posted specs for review
Yep, I read the Reddit thread, had no idea this was possible.
Still, both solutions are ugly workarounds and it would be nice to fix
this properly. But at least I don't have to patch and compile QEMU on my
own anymore.
--
You received this bug notification because you are a member of qemu-
On 07.02.20 07:43, Jan Kiszka wrote:
From: Jan Kiszka
This is helpful when debugging stuck guest timers.
As we need apic_get_current_count for that, and it is really not
emulation specific, move it to apic_common.c and export it. Fix its
style at this chance as well.
Signed-off-by: Jan
On 17.06.20 17:32, Alex Bennée wrote:
>
> Jan Kiszka writes:
>
>> Hi all,
>>
>> as requested by Michael, find below the current version of the Inter-VM
>> Shared Memory device specification version 2 (as version 1 could be
>> considered what is
The problem is caused by the fact that with Ryzen CPUs with disabled
cores, the APIC IDs are not sequential on host - in order for cache
topology to be configured properly, there is a 'hole' in APIC ID and
core ID numbering (I have added full output of cpuid for my 3900X).
Unfortunately, adding
this feature and, thus, could act as a use case to
design against.
Thanks,
Jan
[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg668749.html
---
IVSHMEM Device Specification
** NOTE: THIS IS WORK-IN-PROGRESS, NOT YET A STABLE INTERFACE SPECIFICATION
On 21.05.20 20:18, Michael S. Tsirkin wrote:
> On Thu, May 21, 2020 at 05:53:31PM +0100, Alex Bennée wrote:
>>
>> Jan Kiszka writes:
>>
>>> From: Jan Kiszka
>>>
>>> This imports the ivshmem v2 specification draft from Jailhouse where the
>>
h-sieger,
that is a misunderstanding, read my comment carefully again:
"A workaround for Linux VMs is to disable CPUs (and setting their
number/pinnings accordingly, e.g. every 4th (and 3rd for 3100) core is going to
be 'dummy' and disabled system-wide) by e.g. echo 0 >
adds "host-cache-info=on,l3-cache=off"
to the qemu -cpu args
I believe l3-cache=off is useless with host-cache-info=on
So should do what you want.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Damir:
Hm, must be some misconfiguration, then. My config for Linux VMs to utilize 3
out of the 4 CCXs. Important parts of the libvirt domain XML:
24
1
No, creating artificial NUMA nodes is, simply put, never a good solution
for CPUs that operate as a single NUMA node - which is the case for all
Zen2 CPUs (except maybe EPYCs? not sure about those).
You may workaround the L3 issue that way, but hit many new bugs/problems
by introducing multiple
A workaround for Linux VMs is to disable CPUs (and setting their
number/pinnings accordingly, e.g. every 4th (and 3rd for 3100) core is
going to be 'dummy' and disabled system-wide) by e.g. echo 0 >
/sys/devices/system/cpu/cpu3/online
No good workaround for Windows VMs exists, as far as I know -
The problem is that disabled cores are not taken into account.. ALL Zen2
CPUs have L3 cache group per CCX and every CCX has 4 cores, the problem
is that some cores in each CCX (1 for 6 and 12-core CPUs, 2 for 3100)
are disabled for some models, but they still use their core ids (as can
be seen in
Same problem here on 5.0 and 3900x (3 cores per CCX). And as stated
before - declaring NUMA nodes is definitely not the right solution if
the aim is to emulate the host CPU as close as possible.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
);
/* Register flash */
dinfo = drive_get(IF_PFLASH, 0, 0);
I don't recall details anymore either (more than 10 year ago now...),
but this looks reasonable.
Reviewed-by: Jan Kiszka
Jan
frontend will show
localhost:~ # [ 1312.284301] virtio-ivshmem :00:04.0: backend failed!
Tested-by: Liang Yan
Thanks for testing this! I'll look into your patch findings.
Jan
On 1/7/20 9:36 AM, Jan Kiszka wrote:
Overdue update of the ivshmem 2.0 device model as presented at [1].
Changes
On 09.04.20 15:52, Liang Yan wrote:
On 1/7/20 9:36 AM, Jan Kiszka wrote:
Overdue update of the ivshmem 2.0 device model as presented at [1].
Changes in v2:
- changed PCI device ID to Siemens-granted one,
adjusted PCI device revision to 0
- removed unused feature register from device
From: Jan Kiszka
vtd_irte_get failed to check the index against the configured table
size, causing an out-of-bounds access on guest memory and potentially
misinterpreting the result.
Signed-off-by: Jan Kiszka
---
BTW, we still miss error reporting emulation, right? Therefore, I added
On 08.02.20 17:10, Philippe Mathieu-Daudé wrote:
Fix bug report from Jan Kiszka:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg678130.html
https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg02260.html
Supersedes: <20200208143008.6157-1-f4...@amsat.org>
Philippe Mathieu-Da
On 08.02.20 16:20, Jan Kiszka wrote:
> On 08.02.20 15:30, Philippe Mathieu-Daudé wrote:
>> Fix using virtual console under gtk 3.22.30 (mate 1.20.1):
>>
>> qemu-system-x86_64: Gdk: gdk_window_get_origin: assertion
>> 'GDK_IS_WINDOW (window)' failed
>>
&g
On 08.02.20 15:30, Philippe Mathieu-Daudé wrote:
Fix using virtual console under gtk 3.22.30 (mate 1.20.1):
qemu-system-x86_64: Gdk: gdk_window_get_origin: assertion 'GDK_IS_WINDOW
(window)' failed
Fixes: c4c00922cc and 28b58f19d2 (display/gtk: get proper refreshrate)
Reported-by: Jan
t; -refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
> +refresh_rate_millihz = gd_refresh_rate_millihz(s);
> if (refresh_rate_millihz) {
> vc->gfx.dcl.update_interval = MILLISEC_PER_SEC /
> refresh_rate_millihz;
> }
>
This (as well as c4c00922cc) gives
qemu-system-x86_64: Gdk: gdk_window_get_origin: assertion 'GDK_IS_WINDOW
(window)' failed
on startup under gtk 3.22.30 (mate 1.20.1).
Jan
From: Jan Kiszka
This is helpful when debugging stuck guest timers.
As we need apic_get_current_count for that, and it is really not
emulation specific, move it to apic_common.c and export it. Fix its
style at this chance as well.
Signed-off-by: Jan Kiszka
Reviewed-by: Philippe Mathieu-Daudé
On 06.02.20 23:36, Philippe Mathieu-Daudé wrote:
> On 2/6/20 8:50 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> This is helpful when debugging stuck guest timers.
>>
>> As we need apic_get_current_count for that, and it is really not
>> emulation specif
From: Jan Kiszka
This is helpful when debugging stuck guest timers.
As we need apic_get_current_count for that, and it is really not
emulation specific, move it to apic_common.c and export it.
Signed-off-by: Jan Kiszka
---
hw/intc/apic.c | 18 --
hw/intc
a pragmatic shortcut, not a generic model.
The patches should clarify their use case a bit further, I think. The
title suggests a generic sharing solution, but my impression is that it
rather caters a specific case under specific boundary conditions.
Jan
--
Siemens AG, Corporate Technology, CT RDA
From: Jan Kiszka
This adds a reimplementation of ivshmem in its new revision 2 as
separate device. The goal of this is not to enable sharing with v1,
rather to allow explore the properties and potential limitation of the
new version prior to discussing its integration with the existing code.
v2
From: Jan Kiszka
This imports the ivshmem v2 specification draft from Jailhouse where the
implementation is about to be merged now. The final home of the spec is
to be decided, this shall just simplify the review process at this
stage.
Signed-off-by: Jan Kiszka
---
docs/specs/ivshmem-2-device
From: Jan Kiszka
This implements the server process for ivshmem v2 device models of QEMU.
Again, no effort has been spent yet on sharing code with the v1 server.
Parts have been copied, others were rewritten.
In addition to parameters of v1, this server now also specifies
- the maximum number
an start the QEMU frontend instance with the
virtio-ivshmem driver installed which can use the new /dev/hvc* or
/dev/vda* as usual.
Any feedback welcome!
Jan
PS: Let me know if I missed someone potentially interested in this topic
on CC - or if you would like to be dropped from the list.
[1] http
On 05.12.19 12:14, Markus Armbruster wrote:
> This has been on the list for more than three weeks already. I
> apologize for the delay.
No problem! Your feedback is highly appreciated.
>
> Jan Kiszka writes:
>
>> From: Jan Kiszka
>>
>> This imports the iv
On 03.12.19 06:53, Liang Yan wrote:
>
> On 12/2/19 1:16 AM, Jan Kiszka wrote:
>> On 27.11.19 18:19, Jan Kiszka wrote:
>>> Hi Liang,
>>>
>>> On 27.11.19 16:28, Liang Yan wrote:
>>>>
>>>>
>>>> On 11/11/19 7:57 AM, Jan Kis
On 27.11.19 18:19, Jan Kiszka wrote:
Hi Liang,
On 27.11.19 16:28, Liang Yan wrote:
On 11/11/19 7:57 AM, Jan Kiszka wrote:
To get the ball rolling after my presentation of the topic at KVM Forum
[1] and many fruitful discussions around it, this is a first concrete
code series. As discussed
Hi Liang,
On 27.11.19 16:28, Liang Yan wrote:
On 11/11/19 7:57 AM, Jan Kiszka wrote:
To get the ball rolling after my presentation of the topic at KVM Forum
[1] and many fruitful discussions around it, this is a first concrete
code series. As discussed, I'm starting with the IVSHMEM
On 12.11.19 09:04, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 05:38:29PM +0100, Jan Kiszka wrote:
On 11.11.19 17:11, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 03:27:43PM +, Daniel P. Berrangé wrote:
On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
On Mon
On 11.11.19 17:11, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 03:27:43PM +, Daniel P. Berrangé wrote:
On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 02:59:07PM +0100, Jan Kiszka wrote:
On 11.11.19 14:45, Michael S. Tsirkin wrote:
On Mon
On 11.11.19 17:14, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 04:42:52PM +0100, Jan Kiszka wrote:
On 11.11.19 16:27, Daniel P. Berrangé wrote:
On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 02:59:07PM +0100, Jan Kiszka wrote:
On 11.11.19 14
On 11.11.19 16:27, Daniel P. Berrangé wrote:
On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 02:59:07PM +0100, Jan Kiszka wrote:
On 11.11.19 14:45, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 01:57:11PM +0100, Jan Kiszka wrote:
+| Offset
On 11.11.19 14:45, Michael S. Tsirkin wrote:
On Mon, Nov 11, 2019 at 01:57:11PM +0100, Jan Kiszka wrote:
+| Offset | Register | Content
From: Jan Kiszka
This adds a reimplementation of ivshmem in its new revision 2 as
separate device. The goal of this is not to enable sharing with v1,
rather to allow explore the properties and potential limitation of the
new version prior to discussing its integration with the existing code.
v2
-ivshmem-console /dev/uio0 /path/to/disk.img
After that, you can start the QEMU frontend instance with the
virtio-ivshmem driver installed which can use the new /dev/hvc* or
/dev/vda* as usual.
Any feedback welcome!
Jan
PS: Let me know if I missed someone potentially interested in this topic
on
From: Jan Kiszka
This imports the ivshmem v2 specification draft from Jailhouse. Its
final home is to be decided, this shall just simplify the review process
at this stage.
Note that specifically the Features register (offset 08h) is still under
consideration. In particular, its bit 0 seems
From: Jan Kiszka
This implements the server process for ivshmem v2 device models of QEMU.
Again, no effort has been spent yet on sharing code with the v1 server.
Parts have been copied, others were rewritten.
In addition to parameters of v1, this server now also specifies
- the maximum number
On 27.07.19 12:00, Marc-André Lureau wrote:
Hi
On Sat, Jul 27, 2019 at 10:16 AM Jan Kiszka wrote:
From: Jan Kiszka
I haven't been doing anything here for a long time, nor does my git repo
still play a role.
Signed-off-by: Jan Kiszka
too bad, we could still use some help ;)
thanks
On 03.08.19 15:22, Jan Kiszka wrote:
From: Jan Kiszka
Allows to shutdown a foreground session via ctrl-c.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- adjust error message
contrib/ivshmem-server/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib
On 06.08.19 15:01, Claudio Fontana wrote:
On 8/5/19 7:54 AM, Jan Kiszka wrote:
From: Jan Kiszka
So far, the server leaves the posix shared memory object behind when
terminating, requiring the user to explicitly remove it in order to
start a new instance.
Signed-off-by: Jan Kiszka
On Fri, Oct 11, 2019 at 10:18:18AM +0200, Paolo Bonzini wrote:
> On 11/10/19 08:05, Jan Glauber wrote:
> > On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> >>> ...but if I bump notify_me size to uint64_t the issue goes away.
> >>
> >> Ouch.
On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> On 09/10/19 10:02, Jan Glauber wrote:
> > I'm still not sure what the actual issue is here, but could it be some bad
> > interaction between the notify_me and the list_lock? The are both 4 byte
> > and side-by-s
On Mon, Oct 07, 2019 at 04:58:30PM +0200, Paolo Bonzini wrote:
> On 07/10/19 16:44, dann frazier wrote:
> > On Mon, Oct 07, 2019 at 01:06:20PM +0200, Paolo Bonzini wrote:
> >> On 02/10/19 11:23, Jan Glauber wrote:
> >>> I've looked into this on Thund
On Mon, Oct 07, 2019 at 01:06:20PM +0200, Paolo Bonzini wrote:
> On 02/10/19 11:23, Jan Glauber wrote:
> > I've looked into this on ThunderX2. The arm64 code generated for the
> > atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> > memory barriers. It i
Debug files for aio-posix generated on 18.04 on ThunderX2.
Compiler:
gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)
Distro:
Ubuntu 18.04.3 LTS
** Attachment added: "aio-posix.tar.xz"
https://bugs.launchpad.net/qemu/+bug/1805256/+attachment/5293619/+files/aio-posix.tar.xz
--
You
On Wed, Oct 02, 2019 at 11:45:19AM +0200, Paolo Bonzini wrote:
> On 02/10/19 11:23, Jan Glauber wrote:
> > I've tried to verify me theory with this patch and didn't run into the
> > issue for ~500 iterations (usually I would trigger the issue ~20
> > iterations).
>
I said the used atomics don't generate any barriers at all.
I've tried to verify me theory with this patch and didn't run into the
issue for ~500 iterations (usually I would trigger the issue ~20 iterations).
--Jan
diff --git a/util/aio-posix.c b/util/aio-posix.c
index d8f0cb4af8dd..d07d
On 29.08.19 20:00, Philippe Mathieu-Daudé wrote:
Hi Jan,
On 8/27/19 9:49 PM, Eduardo Habkost wrote:
On Sun, Aug 25, 2019 at 04:58:18PM +0200, Jan Kiszka wrote:
On 21.07.19 10:58, Jan Kiszka wrote:
From: Jan Kiszka
nb_queue was not zeroed so that we no longer delivered events if a
previous
urn xen_pt_word_reg_write(s, cfg_entry, val, dev_value, valid_mask);
I think you also need to clear the bit before handing on the request,
such that reads will always observe it clear.
Jan
to everyone who made this possible!
Best,
-Jan Bobek
GSOC WORK PRODUCT SUBMISSION
TITLE: Support for AVX within TCG
DATE: 08/25/2019
AUTHOR: Jan Bobek
MENTOR: Richard Henderson
I. SUMMARY
The goal of this GSoC project was to implement support for AVX
instructions in the i386 TCG front-end
On 21.07.19 10:58, Jan Kiszka wrote:
From: Jan Kiszka
nb_queue was not zeroed so that we no longer delivered events if a
previous guest left the device in an overflow state.
The state of absolute does not matter as the next vmmouse_update_handler
call will align it again.
Signed-off-by: Jan
Add all the AVX2 vector instruction entries to sse-opcode.inc.h.
Signed-off-by: Jan Bobek
---
target/i386/sse-opcode.inc.h | 362 ++-
1 file changed, 359 insertions(+), 3 deletions(-)
diff --git a/target/i386/sse-opcode.inc.h b/target/i386/sse-opcode.inc.h
index
1 - 100 of 6016 matches
Mail list logo
