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
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 because we no
>> longer need to track whether we're in the middle of a PS/2 multibyte
>> key sequence.
>>
>> In the conversion
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
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
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 the modules are already loaded, and I do 'lx-symbols', all work fine.
> But, if I load a kernel module after 'lx-symbols', I had this issue:
>
> [ 5093.393940]
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
ed, Jul 22, 2020 at 11:15:43AM +0200, Jan Kiszka wrote:
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 Embe
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
On 21.07.20 12:49, Alex Bennée wrote:
Stefan Hajnoczi writes:
Thank you everyone who joined!
I didn't take notes but two things stood out:
1. The ivshmem v2 and virtio-vhost-user use cases are quite different
so combining them does not seem realistic. ivshmem v2 needs to be as
simple for
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
Hi,
I've seen this first a couple of weeks ago, ignored it, but it's still there
today with master:
Thread 13 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f90e2ffd700 (LWP 26883)]
0x560ef0bddda7 in get_phys_addr_lpae (env=,
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
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
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 currently in QEMU).
This posting is intended to collect feedback from the virtio community
before officially proposing it to
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
>>
);
/* 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
On 16.01.20 02:12, Philippe Mathieu-Daudé wrote:
> The GdkMonitor was introduced in GTK+ 3.22:
> https://developer.gnome.org/gdk3/stable/api-index-3-22.html#api-index-3.22
>
> If we build with older GTK+, the build fails:
>
> CC ui/gtk.o
>qemu/ui/gtk.c: In function ‘gd_vc_gfx_init’:
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
On 05.02.20 15:39, Stefan Hajnoczi wrote:
On Tue, Feb 04, 2020 at 12:30:42PM +0100, i.kotrasi...@partner.samsung.com
wrote:
From: Igor Kotrasinski
This patchset adds a "memory exposing" device that allows two QEMU
instances to share arbitrary memory regions. Unlike ivshmem, it does not
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
s://kvmforum2019.sched.com/event/TmxI
[2] https://groups.google.com/forum/#!topic/jailhouse-dev/ffnCcRh8LOs
[3] https://groups.google.com/forum/#!topic/jailhouse-dev/HX-0AGF1cjg
Jan Kiszka (3):
hw/misc: Add implementation of ivshmem revision 2 device
docs/specs: Add specification of ivshmem device
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
CC - or if you would like to be dropped from the list.
PPS: The Jailhouse queues are currently out of sync /wrt minor details
of this one, primarily the device ID. Will update them when the general
direction is clear.
[1] https://kvmforum2019.sched.com/event/TmxI
Jan Kiszka (3):
hw/misc: Add
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 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
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
Based on SDM from May 2019.
Signed-off-by: Jan Kiszka
---
scripts/kvm/vmxcap | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 99a8146aaa..d8c7d6dfb8 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -178,7 +178,11 @@ controls
On 05.08.19 10:33, Stefano Garzarella wrote:
> On Sat, Aug 03, 2019 at 03:22:04PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Allows to shutdown a foreground session via ctrl-c.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> Changes in v2
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
---
Changes in v2:
- respect use_shm_open
- also clean up in ivshmem_server_start error
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/ivshmem-server/main.c b/contrib/ivshmem
From: Jan Kiszka
Allows to shutdown a foreground session via ctrl-c.
Signed-off-by: Jan Kiszka
---
contrib/ivshmem-server/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/ivshmem-server/main.c b/contrib/ivshmem-server/main.c
index 197c79c57e..8a81cdb04c
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
---
contrib/ivshmem-server/ivshmem-server.c | 1 +
1 file changed, 1 insertion(+)
diff
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
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d6de200453..238feb965f 100644
--- a/MAINTAINERS
+++ b
On 22.07.19 12:31, Liran Alon wrote:
>> On 22 Jul 2019, at 13:20, Jan Kiszka wrote:
>>
>> On 22.07.19 11:44, Liran Alon wrote:
>>>
>>>
>>>> On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
>>>>
>>>> Writing the nested state e.g.
On 22.07.19 11:44, Liran Alon wrote:
>
>
>> On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
>>
>> Writing the nested state e.g. after a vmport access can invalidate
>> important parts of the kernel-internal state, and it is not needed as
>> well. So leave
Writing the nested state e.g. after a vmport access can invalidate
important parts of the kernel-internal state, and it is not needed as
well. So leave this out from KVM_PUT_RUNTIME_STATE.
Suggested-by: Paolo Bonzini
Signed-off-by: Jan Kiszka
---
target/i386/kvm.c | 10 +-
1 file
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 Kiszka
---
hw/i386/vmmouse.c | 1 +
1
On 03.06.19 02:36, Michael S. Tsirkin wrote:
> On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Masked entries will not generate interrupt messages, thus do no need to
>> be routed by KVM. This is a cosmetic cleanup, just avoid
On 10.07.19 18:34, Paolo Bonzini wrote:
> On 10/07/19 18:08, Jan Kiszka wrote:
>> On 10.07.19 16:40, Paolo Bonzini wrote:
>>> On 08/07/19 20:31, Jan Kiszka wrote:
>>>>> -if (cpu_has_nested_virt(env) && !env->nested_state) {
>>>>> +
On 10.07.19 16:40, Paolo Bonzini wrote:
> On 08/07/19 20:31, Jan Kiszka wrote:
>>> -if (cpu_has_nested_virt(env) && !env->nested_state) {
>>> +if (kvm_enabled() && cpu_has_vmx(env) && !env->nested_state) {
>>>
On 08.07.19 20:31, Jan Kiszka wrote:
>
> On 21.06.19 13:30, Paolo Bonzini wrote:
>> From: Liran Alon
>>
>> Previous commits have added support for migration of nested virtualization
>> workloads. This was done by utilising two new KVM capabil
On 21.06.19 13:30, Paolo Bonzini wrote:
> From: Liran Alon
>
> Previous commits have added support for migration of nested virtualization
> workloads. This was done by utilising two new KVM capabilities:
> KVM_CAP_NESTED_STATE and KVM_CAP_EXCEPTION_PAYLOAD. Both which are
> required in order
On 21.06.19 13:30, Paolo Bonzini wrote:
> From: Liran Alon
>
> Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker")
> added a migration blocker for vCPU exposed with Intel VMX.
> However, migration should also be blocked for vCPU exposed with
> AMD SVM.
>
> Both cases should be
From: Jan Kiszka
No reason to deny this type.
Signed-off-by: Jan Kiszka
---
hw/arm/virt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 431e2900fd..ed009fa447 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -176,6 +176,7 @@ static const int
On 02.06.19 14:10, Peter Xu wrote:
On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
From: Jan Kiszka
Masked entries will not generate interrupt messages, thus do no need to
be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
the kind
qemu-system-x86_64
From: Jan Kiszka
Masked entries will not generate interrupt messages, thus do no need to
be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
the kind
qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0,
high=0xff00, low=0x100)
if the masked entry happens
On 22.03.19 15:01, Luc Michel wrote:
On 3/22/19 2:29 PM, Jan Kiszka wrote:
On 07.12.18 10:01, Luc Michel wrote:
Add the gdb_first_attached_cpu() and gdb_next_attached_cpu() to iterate
over all the CPUs in currently attached processes.
Add the gdb_first_cpu_in_process
On 07.12.18 10:01, Luc Michel wrote:
> Add the gdb_first_attached_cpu() and gdb_next_attached_cpu() to iterate
> over all the CPUs in currently attached processes.
>
> Add the gdb_first_cpu_in_process() and gdb_next_cpu_in_process() to
> iterate over CPUs of a given process.
>
> Use them to add
On 21.02.19 17:48, Markus Armbruster wrote:
Jan Kiszka writes:
On 21.02.19 17:05, Eric Blake wrote:
On 2/21/19 9:53 AM, David Kiarie wrote:
the occurrence of my name and email on the files below may have led to
some confusion in the reporting of a few recent bugs.
i have therefore choosen
On 21.02.19 17:05, Eric Blake wrote:
On 2/21/19 9:53 AM, David Kiarie wrote:
the occurrence of my name and email on the files below may have led to
some confusion in the reporting of a few recent bugs.
i have therefore choosen to snip it.
Dropping an email from the copyright line makes
Signed-off-by: Jan Kiszka
---
target/i386/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9313602d3d..1fe3a73a10 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -3677,6 +3677,10 @@ int kvm_arch_fixup_msi_route(struct
kvm_irq_routing_en
On 2018-07-05 10:00, Jan Kiszka wrote:
> On 2018-07-05 08:51, Jan Kiszka wrote:
>> On 2018-06-29 15:29, Luc Michel wrote:
>>> Add support for GICv2 virtualization extensions by mapping the necessary
>>> I/O regions and connecting the maintenance IRQ lines.
>
On 2018-07-05 08:51, Jan Kiszka wrote:
> On 2018-06-29 15:29, Luc Michel wrote:
>> Add support for GICv2 virtualization extensions by mapping the necessary
>> I/O regions and connecting the maintenance IRQ lines.
>>
>> Declare those additions in the device tree and in th
On 2018-06-29 15:29, Luc Michel wrote:
> Add support for GICv2 virtualization extensions by mapping the necessary
> I/O regions and connecting the maintenance IRQ lines.
>
> Declare those additions in the device tree and in the ACPI tables.
>
> Signed-off-by: Luc Michel
> ---
>
On 2018-07-02 05:40, Jason Wang wrote:
>
>
> On 2018年06月30日 14:13, Jan Kiszka wrote:
>> On 2018-04-05 19:41, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> Only signal MSI/MSI-X events on rising edges. So far we re-triggered the
>>>
On 2018-04-05 19:41, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Only signal MSI/MSI-X events on rising edges. So far we re-triggered the
> interrupt sources even if the guest did no consumed the pending one,
> easily causing interrupt storms.
>
> Issue was observable with Lin
From: Jan Kiszka
This implements NPT suport for SVM by hooking into
x86_cpu_handle_mmu_fault where it reads the stage-1 page table. Whether
we need to perform this 2nd stage translation, and how, is decided
during vmrun and stored in hflags2, along with nested_cr3 and
nested_pg_mode
On 2018-06-30 08:05, Paolo Bonzini wrote:
> On 30/06/2018 07:25, Jan Kiszka wrote:
>> On 2018-06-27 14:14, Paolo Bonzini wrote:
>>> On 03/04/2018 17:36, Jan Kiszka wrote:
>>>>
>>>> +static hwaddr get_hphys(CPUState *cs, hwa
On 2018-06-27 14:14, Paolo Bonzini wrote:
> On 03/04/2018 17:36, Jan Kiszka wrote:
>>
>> +static hwaddr get_hphys(CPUState *cs, hwaddr gphys, MMUAccessType
>> access_type,
>> +int *prot)
>> +{
>> +CPUX86State *env = _C
On 2018-06-26 12:22, Jan Kiszka wrote:
> On 2018-06-26 11:24, Luc Michel wrote:
>>
>>
>> On 06/25/2018 06:55 AM, Jan Kiszka wrote:
>>> On 2018-06-19 11:31, luc.mic...@greensocs.com wrote:
>>>> From: Luc MICHEL
>>>>
>>>&g
On 2018-06-26 11:24, Luc Michel wrote:
>
>
> On 06/25/2018 06:55 AM, Jan Kiszka wrote:
>> On 2018-06-19 11:31, luc.mic...@greensocs.com wrote:
>>> From: Luc MICHEL
>>>
>>> This patch series add support for the virtualization extensions
On 2018-06-19 11:31, luc.mic...@greensocs.com wrote:
> From: Luc MICHEL
>
> This patch series add support for the virtualization extensions in the
> ARM GICv2 interrupt controller.
>
> The first two commits do some refactoring to prepare for the
> implementation. Commits 3 and 4 are the actual
06月13日 03:00, Philippe Mathieu-Daudé wrote:
>>>>> Cc'ing Jason who is also listed as co-maintainer:
>>>>>
>>>>> ./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
>>>>> Dmitry Fleytman (maintainer:e1000e)
>>>>> Jas
On 2018-06-13 16:26, Michael S. Tsirkin wrote:
> On Tue, May 22, 2018 at 09:06:56AM +0200, Jan Kiszka wrote:
>> On 2018-03-29 14:51, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> Counting from the IVHD ID field to the all-devices entry, we have 28
>>&
On 2018-06-12 20:38, Philippe Mathieu-Daudé wrote:
> On 06/12/2018 03:30 PM, Jan Kiszka wrote:
>> On 2018-06-12 20:11, Philippe Mathieu-Daudé wrote:
>>> Hi Jan,
>>>
>>> On 06/12/2018 02:22 PM, Jan Kiszka wrote:
>>>> On 2018-05-22 09:00, Jan Kiszka
On 2018-06-12 20:11, Philippe Mathieu-Daudé wrote:
> Hi Jan,
>
> On 06/12/2018 02:22 PM, Jan Kiszka wrote:
>> On 2018-05-22 09:00, Jan Kiszka wrote:
>>> On 2018-04-16 17:29, Peter Maydell wrote:
>>>> On 16 April 2018 at 16:25, Jan Kiszka wrote:
>>
1 - 100 of 5319 matches
Mail list logo
