a PV guest per default and Linux doesn't support running as
> a
> 32-bit PV guest since a few years now, I guess there is no need to support
> qemu
> as 32-bit on x86 for Xen.
Yet then, just to mention it, you can run a 64-bit PV Dom0 kernel underneath
an otherwise 32-bit distro. I've been doing this successfully for very many
years (with a very small kernel adjustment, just to work around an apparent
shortcoming in system init scripts).
Jan
dynamically attach a user-created SD/eMMC device to an existing SD
controller?
In system/vl.c, I found 'default_sdcard', which is disabled in some
cases. I wasn't able to figure out how to use it or if it would help
for this use-case.
Jan
> > Perhaps Cédric can explain how
édric Le Goater
> ---
> docs/system/arm/aspeed.rst | 99 +-
> 1 file changed, 86 insertions(+), 13 deletions(-)
Reviewed-by: Jan Luebbe
On Tue, 2024-10-29 at 15:06 +, Peter Maydell wrote:
> On Fri, 18 Oct 2024 at 16:42, Peter Maydell wrote:
> > On Tue, 15 Oct 2024 at 14:57, Jan Luebbe wrote:
> > > For testing eMMC-specific functionality (such as handling boot
> > > partitions), it would be ve
e booting from an eMMC device and when
> default devices are created, the proposed change still makes sense
> since the device is required to have boot areas.
>
> Cc: Jan Luebbe
> Fixes: e554e45b4478 ("aspeed: Tune eMMC device properties to reflect
> HW strapping")
e booting from an eMMC device and when
> default devices are created, the proposed change still makes sense
> since the device is required to have boot areas.
>
> Cc: Jan Luebbe
> Fixes: e554e45b4478 ("aspeed: Tune eMMC device properties to reflect
> HW strapping")
On Tue, 2024-10-29 at 07:40 -0700, Guenter Roeck wrote:
> On 10/28/24 01:41, Jan Lübbe wrote:
> > On Sun, 2024-10-27 at 20:32 -0700, Guenter Roeck wrote:
> > > On 10/27/24 15:26, Cédric Le Goater wrote:
> > > > On 10/27/24 23:11, Guenter Roeck wrote:
> > >
stead, subtract the boot_part_size directly (twice, as there are two
identical boot partitions defined by the eMMC spec).
Suggested-by: Cédric Le Goater
Signed-off-by: Jan Luebbe
---
hw/sd/sd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
ition and
> > in the modeling too. This avoids "hard-coding" default devices in
> > the machines and lets the user define its own variant models using
> > the QEMU command line.
>
> I would agree, but I had a number of my patches rejected because while
> they
On Fri, 2024-10-25 at 06:59 -0700, Guenter Roeck wrote:
> On 10/25/24 02:57, Jan Lübbe wrote:
> > On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote:
> > > On 10/24/24 19:59, Philippe Mathieu-Daudé wrote:
> > > > Cc'ing Jan.
> > > >
Hi,
On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote:
> On 10/24/24 19:59, Philippe Mathieu-Daudé wrote:
> > Cc'ing Jan.
> >
> > On 22/10/24 12:04, Guenter Roeck wrote:
> > > On 10/21/24 21:09, Philippe Mathieu-Daudé wrote:
> > > > Hi Guent
options above work is to avoid
disabling user_creatable, so do that. The SDHCI-PCI driver in the Linux
kernel already supports this just fine.
Signed-off-by: Jan Luebbe
---
hw/sd/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index a5d2d929a8af..2d3467c3d956 100644
On Mon, 2024-09-30 at 15:18 +0100, Peter Maydell wrote:
> On Fri, 6 Sept 2024 at 17:51, Jan Luebbe wrote:
> >
> > The enable bits in the EXT_CSD_PART_CONFIG ext_csd register do *not*
> > specify whether the boot partitions exist, but whether they are enabled
> > fo
ed
interrupt that is disabled does not get pending. Thus we have to retain
the get-pending-on-enable logic just for this model. For GICv2 and
later, the pending status is fully handled by gic_test_pending() and
does not need any special treatment when enabling the level interrupt.
Signed-off-by:
On Fri, 2024-09-06 at 13:50 +0100, Peter Maydell wrote:
> On Mon, 2 Sept 2024 at 13:32, Jan Klötzke
> wrote:
> >
> > Level triggered interrupts are pending when either the interrupt line
> > is asserted or the interrupt was made pending by a GICD_ISPENDRn write.
>
,
Linux detects boot partitions of 1M. But as sd_bootpart_offset always
returns 0, all reads/writes are mapped to the same offset in the backing
file.
Fix this bug by calculating the offset independent of which partition is
enabled for booting.
Signed-off-by: Jan Luebbe
---
hw/sd/sd.c | 7
c_test_pending() and does not need any special treatment
when enabling the level interrupt.
Signed-off-by: Jan Klötzke
---
hw/intc/arm_gic.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 806832439b..10fc9bfd14 100644
--- a/hw/intc/arm
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
x27;s the issue with sound, though. 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
suggest "suitably 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 them
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 u
;enable_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
> disabl
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
://avocado-framework.readthedocs.io/en/latest/config/index.html#nrunner-max-parallel-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
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_pr
ciate 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&#x
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 rest
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 wi
** 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 fo
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 Le
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"
> >
> &
if the EBUSY error happens because something 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
butions 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
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 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 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
e not in self.loaded_modules:
> 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
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..
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/targe
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
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
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
m-virtio, allowing the same
device backend 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-by
o is fine, also 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 r
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-
devel
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 cu
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 hol
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 >
/sys/devices/system/cpu/c
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.
https://bugs.launchpad.net/bugs/1
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 NU
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 - t
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 v
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
NDIAN);
/* 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].
Cha
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
that
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
&
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)
Report
= con;
>
> -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 specific,
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
idirectional,
that rather looks like 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
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 Kiszka
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 IV
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
tio/virtio-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 topi
1 - 100 of 6150 matches
Mail list logo
