RE: Xen 4.14 RC1

> -Original Message- > From: Tamas K Lengyel > Sent: 08 June 2020 21:03 > To: Xen-devel ; Paul Durrant > Cc: xen-us...@lists.xenproject.org; xen-annou...@lists.xenproject.org > Subject: Re: Xen 4.14 RC1 > > On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: > > > > Hi all, > > > > Xen

Re: Xen 4.14 RC1

On Mon, Jun 08, 2020 at 02:02:31PM -0600, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: > > > > Hi all, > > > > Xen 4.14 RC1 is tagged. You can check that out from xen.git: > > > > git://xenbits.xen.org/xen.git 4.14.0-rc1 > > > > For your convenience there is also a

RE: [PATCH v1] kdd: remove zero-length arrays

> -Original Message- > From: Xen-devel On Behalf Of Olaf > Hering > Sent: 08 June 2020 21:39 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Olaf Hering ; > Tim Deegan ; > Wei Liu > Subject: [PATCH v1] kdd: remove zero-length arrays > > Struct 'kdd_hdr' already has a member na

Re: [PATCH v1] kdd: remove zero-length arrays

Am Tue, 9 Jun 2020 09:55:52 +0100 schrieb Paul Durrant : > Is it not sufficient to just change the declaration of payload in kdd_pkt > from [0] to []? AFAIR this lead to compile errors. Olaf pgpeRRQw92FvJ.pgp Description: Digitale Signatur von OpenPGP

RE: [PATCH v1] kdd: remove zero-length arrays

> -Original Message- > From: Olaf Hering > Sent: 09 June 2020 10:00 > To: Paul Durrant > Cc: p...@xen.org; xen-devel@lists.xenproject.org; 'Ian Jackson' > ; 'Tim > Deegan' ; 'Wei Liu' > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > Am Tue, 9 Jun 2020 09:55:52 +0100 > schri

Re: [PATCH v1] kdd: remove zero-length arrays

On 09.06.20 11:04, Paul Durrant wrote: -Original Message- From: Olaf Hering Sent: 09 June 2020 10:00 To: Paul Durrant Cc: p...@xen.org; xen-devel@lists.xenproject.org; 'Ian Jackson' ; 'Tim Deegan' ; 'Wei Liu' Subject: Re: [PATCH v1] kdd: remove zero-length arrays Am Tue, 9 Jun 2020 0

RE: [PATCH v1] kdd: remove zero-length arrays

> -Original Message- > From: Jürgen Groß > Sent: 09 June 2020 10:06 > To: p...@xen.org; 'Olaf Hering' ; 'Paul Durrant' > > Cc: xen-devel@lists.xenproject.org; 'Ian Jackson' > ; 'Wei Liu' ; > 'Tim Deegan' > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > On 09.06.20 11:04, P

Re: Xen 4.14 RC1

On 09.06.2020 10:11, Roger Pau Monné wrote: > On Mon, Jun 08, 2020 at 02:02:31PM -0600, Tamas K Lengyel wrote: >> On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: >>> >>> Hi all, >>> >>> Xen 4.14 RC1 is tagged. You can check that out from xen.git: >>> >>> git://xenbits.xen.org/xen.git 4.14.0-rc

Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events

On 03.06.2020 14:52, Tamas K Lengyel wrote: > For the last couple years we have received numerous reports from users of > monitor vm_events of spurious guest crashes when using events. In particular, > it has observed that the problem occurs when vm_events are being disabled. The > nature of the gu

Re: [PATCH v1] kdd: remove zero-length arrays

Am Tue, 9 Jun 2020 10:04:30 +0100 schrieb Paul Durrant : > OOI which compiler (might be worth mentioning in the commit comment too, for > reference)? I'm not seeing a problem. This is from gcc10. I think the build automation for Tumbleweed will show this error, unless the Tumbleweed image is ol

[qemu-mainline test] 150930: tolerable FAIL - PUSHED

flight 150930 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150930/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd6

XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

Hi, I've been making progress on bootstrapping a new, PVHv2 only, Xen platform stack for MirageOS [1]. The basics are now functional and I have started to re-implement the grant table code. After studying both the Mini-OS and Linux implementations some, I don't understand the difference between u

RE: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events

> -Original Message- > From: Jan Beulich > Sent: 09 June 2020 10:37 > To: Tamas K Lengyel > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Wei Liu ; > Roger Pau Monné ; George Dunlap > ; Ian Jackson > ; Julien Grall ; Stefano Stabellini > ; Alexandru Isaila ; Petre > Pircalabu >

Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

On 09/06/2020 10:44, Martin Lucina wrote: > Hi, > > I've been making progress on bootstrapping a new, PVHv2 only, Xen platform > stack for MirageOS [1]. The basics are now functional and I have started to > re-implement the grant table code. > > After studying both the Mini-OS and Linux implementat

Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

On 05.06.2020 19:37, Andrew Cooper wrote: > On 05/06/2020 08:51, Jan Beulich wrote: >> Both match prior generation processors as far as LBR and C-state MSRs >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum >> (recent spec updates). >> >> Signed-off-by: Jan Beulich >> ---

RE: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers

> -Original Message- > From: Jan Beulich > Sent: 09 June 2020 11:33 > To: Paul Durrant > Cc: Andrew Cooper ; > xen-devel@lists.xenproject.org; Roger Pau Monné > ; Wei Liu > Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers > > On 05.06.2020 19:37, Andrew Coop

Re: [PATCH for-4.14] docs: Minor build improvements

On 08.06.2020 19:15, Andrew Cooper wrote: > Don't use "set -x" for the figs rule. It doesn't take effect in the recursive > make environment. I'd rather view this as an unintended debugging leftover. > Turn the HTML manpage comments into makefile comments, not shell comments. > This saves 3x she

Re: [RFC PATCH 33/35] hw/timer/slavio_timer: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/timer/slavio_timer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c > index

Re: [RFC PATCH 32/35] hw/riscv: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/riscv/riscv_htif.c | 4 > hw/riscv/sifive_uart.c | 4 > 2 files changed, 8 insertions(+) > > diff --git a/hw/riscv/riscv_htif.c

Re: [RFC PATCH 23/35] hw/misc/applesmc: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/misc/applesmc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c > index 1c4addb201..d63

Re: [RFC PATCH 18/35] hw/input/ps2: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/input/ps2.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/hw/input/ps2.c b/hw/input/ps2.c > index f8746d2f5

Re: [RFC PATCH 17/35] hw/input/pckbd: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/input/pckbd.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c > index 60a41

Re: [RFC PATCH 14/35] hw/i386/pc: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/i386/pc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 2128f3d6fe..c71809fd28 100644 > -

Re: [RFC PATCH 06/35] hw/timer/arm_timer: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/timer/arm_timer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c > index 9607366d7

Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

On 9 Jun 2020, at 11:22, Andrew Cooper wrote: > > On 09/06/2020 10:44, Martin Lucina wrote: >> Hi, >> >> I've been making progress on bootstrapping a new, PVHv2 only, Xen platform >> stack for MirageOS [1]. The basics are now functional and I have started to >> re-implement the grant table code.

Re: [RFC PATCH 21/35] hw/lm32/lm32_hwsetup: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/lm32/lm32_hwsetup.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h > index de9

RE: [PATCH for-4.14] docs: Minor build improvements

> -Original Message- > From: Xen-devel On Behalf Of Jan > Beulich > Sent: 09 June 2020 11:42 > To: Andrew Cooper > Cc: Stefano Stabellini ; Julien Grall > ; Wei Liu ; > Konrad Rzeszutek Wilk ; George Dunlap > ; Ian > Jackson ; Xen-devel > Subject: Re: [PATCH for-4.14] docs: Minor b

Re: [RFC PATCH 20/35] hw/intc/i8259: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/intc/i8259.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c > index 51b27f6a34..9d9609cdab 1

Re: [RFC PATCH 29/35] hw/ppc/ppc_booke: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/ppc_booke.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/ppc/ppc_booke.c b/hw/ppc/ppc_booke.c > index

Re: [RFC PATCH 27/35] hw/ppc/ppc: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/ppc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c > index 4a11fb1640..39fcf746c5 100644 > -

Re: [RFC PATCH 26/35] hw/openrisc/cputimer: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/openrisc/cputimer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/openrisc/cputimer.c b/hw/openrisc/cputimer.c > index 932

Re: [RFC PATCH 30/35] hw/ppc/virtex_ml507: Emit warning when old code is used

On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/virtex_ml507.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.

Re: [RFC PATCH 00/35] hw/qdev: Warn when using pre-qdev/QOM devices

On 08/06/20 18:17, Philippe Mathieu-Daudé wrote: > On 6/8/20 6:14 PM, Peter Maydell wrote: >> On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé >> wrote: >>> >>> Based on today's IRC chat, this is a trivial RFC series >>> to anotate pre-qdev/QOM devices so developers using them >>> without know

[libvirt test] 150932: tolerable all pass - PUSHED

flight 150932 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150932/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 146182 test-armhf-armhf-libvirt-raw 13 saveresto

Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

On 09/06/2020 11:50, Anil Madhavapeddy wrote: On 9 Jun 2020, at 11:22, Andrew Cooper > wrote: On 09/06/2020 10:44, Martin Lucina wrote: Hi, I've been making progress on bootstrapping a new, PVHv2 only, Xen platform stack for MirageOS [1]. The basics are no

[XEN PATCH for-4.14 2/2] docs-parse-support-md: Cope with buster's pandoc

Provide the implementation for newer pandoc json. I have done an adhoc test and this now works on both buster and stretch and seems to produce the expected support matrix when run using the example rune (which processes unstable and 4.11). Signed-off-by: Ian Jackson --- docs/parse-support-md |

[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions

Different pandoc versions generate, and expect, a different toplevel structure for their json output and inpout. Newer pandoc's toplevel is a hash. We are going to want to support this. We can tell what kind of output we should produce by looking at the input we got (which itself came from pando

Re: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions

Ian Jackson writes ("[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions"): > Different pandoc versions generate, and expect, a different toplevel > structure for their json output and inpout. Newer pandoc's toplevel > is a hash. We are going to want to suppo

RE: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions

> -Original Message- > From: Ian Jackson > Sent: 09 June 2020 12:34 > To: xen-devel@lists.xenproject.org; Andrew Cooper > ; Paul Durrant > > Subject: Re: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for > copying with pandoc versions > > Ian Jackson writes ("[XEN PATCH for-4

[linux-linus test] 150931: tolerable FAIL - PUSHED

flight 150931 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150931/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150910 test-amd64-amd64-xl-qemut-win7-amd64

Re: [PATCH v1] kdd: remove zero-length arrays

Hi, At 09:55 +0100 on 09 Jun (1591696552), Paul Durrant wrote: > > -Original Message- > > From: Xen-devel On Behalf Of Olaf > > Hering > > Sent: 08 June 2020 21:39 > > To: xen-devel@lists.xenproject.org > > Cc: Ian Jackson ; Olaf Hering ; > > Tim Deegan ; > > Wei Liu > > Subject: [PATC

Re: [PATCH v1] tools: fix usage of strncpy

On Mon, Jun 8, 2020 at 10:11 AM Olaf Hering wrote: > > Am Mon, 8 Jun 2020 08:43:50 -0400 > schrieb Jason Andryuk : > > > I added a length check in this patch: > > gcc will not recognize such runtime checks and will (most likely) complain > about the strncpy usage anyway, just as it does now in >

Re: [PATCH v2] libxl__prepare_sockaddr_un

Olaf Hering writes ("[PATCH v2] libxl__prepare_sockaddr_un"): > libxl: remove usage of strncpy from libxl__prepare_sockaddr_un > > The runtime check for the length of path already prevents malfunction. > But gcc does not detect this runtime check and reports incorrect > usage of strncpy. Remove th

Re: [xen-unstable test] 150928: regressions - FAIL

osstest service owner writes ("[xen-unstable test] 150928: regressions - FAIL"): > flight 150928 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/150928/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > b

Re: [PATCH v1] tools: fix usage of strncpy

Am Tue, 9 Jun 2020 08:33:12 -0400 schrieb Jason Andryuk : > What version of gcc are you using? I was using 9.x and it didn't warn from > what I can remember. This is gcc10 from current Tumbleweed. For libxl strcpy will certainly work because the length check is done prior the copying of data.

Re: [PATCH v2] libxl__prepare_sockaddr_un

Am Tue, 9 Jun 2020 14:00:31 +0100 schrieb Ian Jackson : > Why do you not use strcpy here ? Either variant of 'cpy' will work in this context. I decided to use memcpy for no specific reason. Olaf pgpdJBOoXbiGd.pgp Description: Digitale Signatur von OpenPGP

Re: [PATCH v1] kdd: remove zero-length arrays

Am Tue, 9 Jun 2020 13:15:49 +0100 schrieb Tim Deegan : > Olaf, can you try dropping the 'payload' field from the header and replacing > the payload[0] in pkt with payload[] ? In file included from kdd.c:53: kdd.h:325:17: error: flexible array member in union 325 | uint8_t payload[]; -

Re: [PATCH v1] kdd: remove zero-length arrays

Olaf Hering writes ("Re: [PATCH v1] kdd: remove zero-length arrays"): > Am Tue, 9 Jun 2020 13:15:49 +0100 > schrieb Tim Deegan : > > > Olaf, can you try dropping the 'payload' field from the header and > > replacing the payload[0] in pkt with payload[] ? > > In file included from kdd.c:53: > kdd

Re: [PATCH v1] kdd: remove zero-length arrays

Am Tue, 9 Jun 2020 14:26:46 +0100 schrieb Ian Jackson : > +uint8_t payload[]; This compiles, but will access memory behind the union{};, which is most likely not what the intention is. Olaf pgpxOU96iXev2.pgp Description: Digitale Signatur von OpenPGP

Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks

On 08.06.2020 22:02, Andrew Cooper wrote: > Do we ever write into .rodata? AFAICT, we introduce new fuctions for > references to new .rodata, rather than modifying existing .rodata. If however > we do modify .rodata, then the virtual regions need extending with information > about .rodata so we c

[xen-unstable-smoke test] 150935: tolerable all pass - PUSHED

flight 150935 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150935/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

TESTDAY Report: Unexpected results for xenhyps

Playing around with the new `xenhypfs` binary, got some unexpected results: * Unexpected error message for non-existent nodes Command executed: # xenhypfs cat /params/loglvlx could not read: Operation not permitted Expected behavior: -ENOENT-style message Actual behavior: -EACCESS-style message

Re: Keystone Issue

There does appear to be a secondary (CIC) controller that can forward events to the GIC-400 and EDMA controllers for the keystone 2 family. Admittedly, i'm not sure how it is being used with regards to the peripherals. I only see mention of the GIC-400 parent for the devices in the device tree. M

Re: [Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)

On Fri, Nov 15, 2019 at 1:31 PM Paul Durrant wrote: > On Thu, 14 Nov 2019 at 04:57, Julian Tuminaro > wrote: > > > > From: Julian Tuminaro and Jenish Rakholiya and rakholiyajenish...@gmail.com> > > > > Current implementation of find_os is based on the hard-coded values for > > different Windows

[PATCH for-4.14 2/2] tools: fix setting of errno in xenhypfs_read_raw()

Setting of errno is wrong in xenhypfs_read_raw(), fix it. Reported-by: George Dunlap Signed-off-by: Juergen Gross --- tools/libs/hypfs/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c index fc23b02586..f94c5ea1e2 100

[PATCH for-4.14 0/2] tools: two minor fixes for libxenhypfs

Two fixes for libxenhypfs: - xenhypfs terminating with segfault when hypervisor doesn't have hypfs support - wrong error reporting in case for access errors with xenhypfs Juergen Gross (2): tools: fix error path of xenhypfs_open() tools: fix setting of errno in xenhypfs_read_raw() tools/l

[PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open()

In case of an error in xenhypfs_open() the error path will cause a segmentation fault due to a wrong sequence of closing calls. Reported-by: Andrew Cooper Signed-off-by: Juergen Gross --- tools/libs/hypfs/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libs/hypf

RE: [PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open()

> -Original Message- > From: Juergen Gross > Sent: 09 June 2020 15:49 > To: xen-devel@lists.xenproject.org > Cc: p...@xen.org; Juergen Gross ; Ian Jackson > ; Wei Liu > ; Andrew Cooper > Subject: [PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open() > > In case of an error in xe

Re: [Xen-devel] [PATCH v6 00/12] livepatch: new features and fixes

On Tue, Nov 26, 2019 at 10:14 AM Pawel Wieczorkiewicz wrote: > This series introduces new features to the livepatch functionality as > briefly discussed during Xen Developer Summit 2019: [a] and [b]. > It also provides a few fixes and some small improvements. > > Main changes in v6: > - Added mis

RE: [PATCH for-4.14 2/2] tools: fix setting of errno in xenhypfs_read_raw()

> -Original Message- > From: Juergen Gross > Sent: 09 June 2020 15:49 > To: xen-devel@lists.xenproject.org > Cc: p...@xen.org; Juergen Gross ; Ian Jackson > ; Wei Liu > ; George Dunlap > Subject: [PATCH for-4.14 2/2] tools: fix setting of errno in > xenhypfs_read_raw() > > Setting of e

RE: [Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)

De-htmling... - From: Xen-devel On Behalf Of George Dunlap Sent: 09 June 2020 15:42 To: Paul Durrant Cc: Wei Liu ; Tim Deegan ; Jenish Rakholiya ; Ian Jackson ; Julian Tuminaro ; George Dunlap ; xen-devel ; Julian Tuminaro Subject: Re: [Xen-devel] [PATCH V2] kdd.c: Add support for initi

Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction

On 08.06.2020 13:04, Paul Durrant wrote: >> From: Jan Beulich >> Sent: 08 June 2020 11:58 >> >> On 08.06.2020 11:46, Paul Durrant wrote: >>> --- a/xen/arch/x86/hvm/ioreq.c >>> +++ b/xen/arch/x86/hvm/ioreq.c >>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, >>> uint64_t

RE: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction

> -Original Message- > From: Jan Beulich > Sent: 09 June 2020 16:08 > To: p...@xen.org > Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ; > 'Marek Marczykowski-Górecki' > > Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with > ioreq server destruction > > On 0

Re: Keystone Issue

Hi, > On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: > > There does appear to be a secondary (CIC) controller that can forward > events to the GIC-400 and EDMA controllers for the keystone 2 family. > Admittedly, i'm not sure how it is being used with regards to the > peripherals. I only see menti

Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction

On 09.06.2020 17:28, Paul Durrant wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 09 June 2020 16:08 >> To: p...@xen.org >> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ; >> 'Marek Marczykowski-Górecki' >> >> Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation

Re: [PATCH for-4.14 0/2] tools: two minor fixes for libxenhypfs

On Tue, Jun 09, 2020 at 04:48:48PM +0200, Juergen Gross wrote: > Two fixes for libxenhypfs: > > - xenhypfs terminating with segfault when hypervisor doesn't have > hypfs support > - wrong error reporting in case for access errors with xenhypfs > > Juergen Gross (2): > tools: fix error path of

[PATCH for-4.14] xen/hypfs: fix loglvl parameter setting

Writing the runtime parameters loglvl or guest_loglvl omits setting the new length of the resulting parameter value. Reported-by: George Dunlap Signed-off-by: Juergen Gross --- xen/drivers/char/console.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/xe

Re: Keystone Issue

On 09/06/2020 16:28, Bertrand Marquis wrote: Hi, On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: There does appear to be a secondary (CIC) controller that can forward events to the GIC-400 and EDMA controllers for the keystone 2 family. Admittedly, i'm not sure how it is being used with regard

Re: Keystone Issue

On Tue, Jun 9, 2020 at 11:47 AM Julien Grall wrote: > > > > On 09/06/2020 16:28, Bertrand Marquis wrote: > > Hi, > > > >> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: > >> > >> There does appear to be a secondary (CIC) controller that can forward > >> events to the GIC-400 and EDMA controllers for

[PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate

From: Paul Durrant Signed-off-by: Paul Durrant --- Cc: Community Manager --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8786c51cb4..cb1566ea5b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,8 @@ The format is based on [Keep a

[PATCH-for-4.14 2/2] CHANGELOG: add revised kdd handshake (supporting Windows 7, 8, and 10)

From: Paul Durrant Signed-off-by: Paul Durrant -- Cc: Community Manager --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index cb1566ea5b..43fd260156 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ The format is based on [Keep a C

[PATCH-for-4.14 0/2] CHANGELOG additions

From: Paul Durrant Paul Durrant (2): CHANGELOG: add 'domid_policy' and domid preservation on migrate CHANGELOG: add revised kdd handshake (supporting Windows 7, 8, and 10) CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) -- 2.17.1

Re: [PATCH v1] tools: fix usage of strncpy

On Jun 8, 2020, at 10:12, Olaf Hering wrote: > > Am Mon, 8 Jun 2020 08:43:50 -0400 > schrieb Jason Andryuk : > >> I added a length check in this patch: > > gcc will not recognize such runtime checks and will (most likely) complain > about the strncpy usage anyway, just as it does now in > li

Re: [PATCH v1] tools: fix usage of strncpy

Am Tue, 9 Jun 2020 12:35:51 -0400 schrieb Rich Persaud : > Is there any reason not to take a patch that builds libvchan with -Werror? The per-subdirectory settings of -Werror should probably become a global -Werror. Someone has to step up and explore that path. Bonus points if -Werror could be d

[TESTDAY] xl restore gives an error too soon after xl save

Somewhat surprising that if you save with -D, you get mysterious error messages for the next so-many seconds: root@immortal:/images# xl save -D c6-01 /images/tmp/c6-01.save Saving to /images/tmp/c6-01.save new xl format (info 0x3/0x0/950) xc: info: Saving domain 19505, type x86 PV xc: Frames: 524

Re: [PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate

> On Jun 9, 2020, at 5:29 PM, Paul Durrant wrote: > > From: Paul Durrant > > Signed-off-by: Paul Durrant Both patches: Acked-by: George Dunlap

[xen-unstable-smoke test] 150936: tolerable all pass - PUSHED

flight 150936 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150936/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

RE: [TESTDAY] xl restore gives an error too soon after xl save

> -Original Message- > From: George Dunlap > Sent: 09 June 2020 17:45 > To: Xen-devel > Cc: Paul Durrant ; Ian Jackson ; Wei > Liu ; Anthony > Perard > Subject: [TESTDAY] xl restore gives an error too soon after xl save > > Somewhat surprising that if you save with -D, you get mysterio

Xen Security Advisory 320 v1 (CVE-2020-0543) - Special Register Buffer speculative side channel

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 Special Register Buffer speculative side channel ISSUE DESCRIPTION = This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org

Re: [TESTDAY] xl restore gives an error too soon after xl save

> On Jun 9, 2020, at 5:56 PM, Paul Durrant wrote: > >> -Original Message- >> From: George Dunlap >> Sent: 09 June 2020 17:45 >> To: Xen-devel >> Cc: Paul Durrant ; Ian Jackson ; Wei >> Liu ; Anthony >> Perard >> Subject: [TESTDAY] xl restore gives an error too soon after xl save >>

Re: Keystone Issue

Hi > On 9 Jun 2020, at 16:47, Julien Grall wrote: > > > > On 09/06/2020 16:28, Bertrand Marquis wrote: >> Hi, >>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>> >>> There does appear to be a secondary (CIC) controller that can forward >>> events to the GIC-400 and EDMA controllers for the k

Re: Keystone Issue

> On 9 Jun 2020, at 16:58, CodeWiz2280 wrote: > > On Tue, Jun 9, 2020 at 11:47 AM Julien Grall wrote: >> >> >> >> On 09/06/2020 16:28, Bertrand Marquis wrote: >>> Hi, >>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: There does appear to be a secondary (CIC) controller that

Re: [PATCH v2 1/8] hw/arm/aspeed: Correct DRAM container region size

Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the aspeed-ram-container > MemoryRegion ends up missing 1

Re: [PATCH v2 6/8] hw/hppa/dino: Use the IEC binary prefix definitions

Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/hppa/dino.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/hp

Re: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions

Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/

Re: Keystone Issue

(+ Marc) On 09/06/2020 18:03, Bertrand Marquis wrote: Hi On 9 Jun 2020, at 16:47, Julien Grall wrote: On 09/06/2020 16:28, Bertrand Marquis wrote: Hi, On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: There does appear to be a secondary (CIC) controller that can forward events to the GIC-400

Re: [PATCH v2 8/8] target/i386/cpu: Use the IEC binary prefix definitions

Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > target/i386/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target

Re: Keystone Issue

Hi Julien, On 2020-06-09 18:32, Julien Grall wrote: (+ Marc) On 09/06/2020 18:03, Bertrand Marquis wrote: Hi On 9 Jun 2020, at 16:47, Julien Grall wrote: On 09/06/2020 16:28, Bertrand Marquis wrote: Hi, On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: There does appear to be a secondary (

[xen-4.10-testing test] 150941: regressions - FAIL

flight 150941 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150941/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 150039 build-i386-pre

[xen-4.11-testing test] 150942: regressions - FAIL

flight 150942 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150942/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 150040 build-amd64-pr

[xen-4.9-testing test] 150940: regressions - FAIL

flight 150940 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150940/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 150120 build-arm64-xsm

[xen-unstable-smoke test] 150939: tolerable all pass - PUSHED

flight 150939 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150939/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

[xen-unstable test] 150933: tolerable FAIL - PUSHED

flight 150933 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150933/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 150918 Tests which did not succeed

Re: Keystone Issue

On Tue, Jun 9, 2020 at 1:45 PM Marc Zyngier wrote: > > Hi Julien, > > On 2020-06-09 18:32, Julien Grall wrote: > > (+ Marc) > > > > On 09/06/2020 18:03, Bertrand Marquis wrote: > >> Hi > >> > >>> On 9 Jun 2020, at 16:47, Julien Grall wrote: > >>> > >>> > >>> > >>> On 09/06/2020 16:28, Bertrand Ma

[xen-4.9-testing test] 150951: regressions - FAIL

flight 150951 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150951/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 150120 build-arm64-xsm

[xen-4.10-testing test] 150952: regressions - FAIL

flight 150952 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-buildfail REGR. vs. 150039 build-amd64-pr

[xen-4.11-testing test] 150953: regressions - FAIL

flight 150953 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 150040 build-armhf

[ovmf test] 150946: tolerable trouble: pass/starved - PUSHED

flight 150946 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150946/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate starved n/a test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts

[xen-unstable-smoke test] 150950: tolerable all pass - PUSHED

flight 150950 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150950/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations

On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote: > > I understand what you are suggesting about having something like: > > > > xen_phys_to_dma(...) > > { > > phys_addr_t phys = xen_phys_to_bus(dev, paddr) > >

  1   2   >