Hi,
> On 9 Jun 2020, at 18:45, 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 Marquis wrote:
> Hi,
>>
Hello,
While adding support for para-virtualized block device in u-boot
I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write.
I tried to use the hypercall during MMU setup stage while enabling data cache
on arm64 platform (e.g. data cache is not yet enabled) and saw in guest's
console
Hi,
> On 9 Jun 2020, at 21:07, CodeWiz2280 wrote:
>
> 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
On 2020-06-10 09:06, Bertrand Marquis wrote:
Hi,
On 9 Jun 2020, at 18:45, 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 Marquis wr
> On 10 Jun 2020, at 09:20, Marc Zyngier wrote:
>
> On 2020-06-10 09:06, Bertrand Marquis wrote:
>> Hi,
>>> On 9 Jun 2020, at 18:45, 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
>> O
flight 151009 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-build fail REGR. vs. 150905
version t
> + - New 'domid_policy', allowing domain-ids to be randomly chosen.
> + - Option to preserve domain-id across migrate or save+restore.
> + - Support in kdd for initial KD protocol handshake for Win 7, 8 and 10 (64
> bit).
These aren't mentioned in SUPPORT.md so their support status
(including se
flight 150976 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150976/
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
flight 150977 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150977/
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
flight 150975 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150120
build-i386-xsm
4.9 to 4.11 don't build on Debian stable, which we are now using in
osstest. This is because they are missing a number of compile fixes.
Where things are straightforward I intend to backport these and push
them to the relevant Xen stable branches without formally posting
about them each here. I
> -Original Message-
> From: Xen-devel On Behalf Of Ian
> Jackson
> Sent: 10 June 2020 12:12
> To: Jan Beulich
> Cc: xen-devel@lists.xenproject.org; committ...@xenproject.org; Wei Liu
>
> Subject: Build fix backports for 4.9 - 4.11 inclusive
>
> 4.9 to 4.11 don't build on Debian stabl
Paul Durrant writes ("RE: Build fix backports for 4.9 - 4.11 inclusive"):
> Something like this is hitting me building 4.11 too. Weirdly it does not hit
> if I do a clean build... only incremental:
Wow. Yes. Same here. With the other stuff I mentioned my 4.10
builds, but only if I start from a
c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat
layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open()
but failed to fix up the error path.
c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in
_open()" fixed up the xencall_ope
The 2017.07 tarball had a leading "./" but the 2019.03 one doesn't,
so we must change CoverityToolsStripComponents.
The old tools we are currently using do not work any more - they are
rejected by Coverity Scan.
Signed-off-by: Ian Jackson
Reported-by: Matthew Krasnick
CC: Jan Beulich
CC: Andre
Edge triggered interrupts do not assert the line, so the handling done
in Xen should also avoid asserting it. Asserting the line prevents
further edge triggered interrupts on the same vIO-APIC pin from being
delivered, since the line is not de-asserted.
One case of such kind of interrupt is the RT
There's no need to setup a timer for GSIs that are edge triggered,
since those don't require any EIO or unmask, and hence couldn't block
other interrupts.
Note this is only used by PVH dom0, that can setup the passthrough of
edge triggered interrupts from the vIO-APIC. One example of such kind
of
Hello,
Small series with two bugfixes to correctly handle edge triggered
interrupts on PVH dom0.
for-4.14 reasoning: fixes are isolated to PVH dom0 specific passthrough
code (IDENTITY_GSI kind of bindings), and hence shouldn't affect
passthrough to HVM domUs. Without these fixes the RTC timer won
On 10/06/2020 12:51, Roger Pau Monne wrote:
> Edge triggered interrupts do not assert the line, so the handling done
> in Xen should also avoid asserting it. Asserting the line prevents
> further edge triggered interrupts on the same vIO-APIC pin from being
> delivered, since the line is not de-ass
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 June 2020 12:51
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered
> GSIs for PVH dom0
On 10/06/2020 12:51, Roger Pau Monne wrote:
> @@ -920,6 +927,11 @@ static void hvm_dirq_assist(struct domain *d, struct
> hvm_pirq_dpci *pirq_dpci)
> if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI )
> {
> hvm_gsi_assert(d, pirq->pirq);
> +if ( pirq_dpc
On Wed, Jun 10, 2020 at 4:39 AM Bertrand Marquis
wrote:
>
>
>
> > On 10 Jun 2020, at 09:20, Marc Zyngier wrote:
> >
> > On 2020-06-10 09:06, Bertrand Marquis wrote:
> >> Hi,
> >>> On 9 Jun 2020, at 18:45, Marc Zyngier wrote:
> >>> Hi Julien,
> >>> On 2020-06-09 18:32, Julien Grall wrote:
>
On Wed, Jun 10, 2020 at 01:33:46PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 10 June 2020 12:51
> > To: xen-devel@lists.xenproject.org
> > Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> > ; Andrew
> > Cooper ; Wei Liu
> > Subject: [PATCH for
On Wed, Jun 10, 2020 at 01:37:15PM +0100, Andrew Cooper wrote:
> On 10/06/2020 12:51, Roger Pau Monne wrote:
> > @@ -920,6 +927,11 @@ static void hvm_dirq_assist(struct domain *d, struct
> > hvm_pirq_dpci *pirq_dpci)
> > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI )
> > {
>
On 10/06/2020 09:13, Oleksandr Andrushchenko wrote:
Hello,
Hi,
While adding support for para-virtualized block device in u-boot
I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write.
I tried to use the hypercall during MMU setup stage while enabling data cache
on arm64 platform (e.
On 2020-06-10 13:39, CodeWiz2280 wrote:
[...]
The problem is that a hack may be my only solution to getting this
working on this platform. If TI says that they don't support it then
i'm stuck. Just to summarize the problem, we believe that the GIC is
seeing secure accesses from dom0 when they
flight 150945 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 150931
Tests which did not
On 10/06/2020 13:39, CodeWiz2280 wrote:
So the only way to solve this is actually to do the interrupt
deactivate inside Xen (using a maintenance interrupt).
That's a terrible hack, and one that would encourage badly integrated HW.
I appreciate the need to "make things work", but I'd be wary
On Tuesday, 09.06.2020 at 11:22, Andrew Cooper wrote:
> There is a little bit of history here...
>
> GNTTABOP_setup_table was the original PV way of doing things (specify
> size as an input, get a list of frames as an output to map), and
> XENMAPSPACE_grant_table was the original HVM way of doing
On 10/06/2020 14:22, Martin Lucina wrote:
> On Tuesday, 09.06.2020 at 11:22, Andrew Cooper wrote:
>> There is a little bit of history here...
>>
>> GNTTABOP_setup_table was the original PV way of doing things (specify
>> size as an input, get a list of frames as an output to map), and
>> XENMAPSPAC
On Wednesday, 10.06.2020 at 14:40, Andrew Cooper wrote:
> > So, going with the grant v2 ABI, is there a modern equivalent of
> > GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be
> > XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and
> > idx=(XENMAPIDX_grant_table
efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
isn't set.
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
mappi
On 10/06/2020 14:56, Martin Lucina wrote:
> On Wednesday, 10.06.2020 at 14:40, Andrew Cooper wrote:
>>> So, going with the grant v2 ABI, is there a modern equivalent of
>>> GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be
>>> XENMEM_add_to_physmap with space=XENMAPSPACE_gr
There's no need to setup a timer for GSIs that are edge triggered,
since those don't require any EIO or unmask, and hence couldn't block
other interrupts.
Note this is only used by PVH dom0, that can setup the passthrough of
edge triggered interrupts from the vIO-APIC. One example of such kind
of
Hello,
Small series with two bugfixes to correctly handle edge triggered
interrupts on PVH dom0.
for-4.14 reasoning: fixes are isolated to PVH dom0 specific passthrough
code (IDENTITY_GSI kind of bindings), and hence shouldn't affect
passthrough to HVM domUs. Without these fixes the RTC timer won
Edge triggered interrupts do not assert the line, so the handling done
in Xen should also avoid asserting it. Asserting the line prevents
further edge triggered interrupts on the same vIO-APIC pin from being
delivered, since the line is not de-asserted.
One case of such kind of interrupt is the RT
On Tue, 17 Mar 2020 18:16:17 +0300
Vladimir Sementsov-Ogievskiy wrote:
> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with an errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> can't see this
On 09/06/2020 14:41, Jan Beulich wrote:
> 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 e
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 June 2020 15:29
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge
> triggered GSIs for PVH do
On Wednesday, 10.06.2020 at 15:21, Andrew Cooper wrote:
> > I don't need v2 at all, I was just going by the comments in grant_table.h,
> > which read: "Version 1 of the grant table entry structure is maintained
> > purely for backwards compatibility. New guests should use version 2."
>
> Ha...
>
On Tue, Jun 9, 2020 at 3:48 AM Paul Durrant wrote:
>
> > -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
> > ; Julie
Hi Juergen,
On 09/06/2020 16:45, Juergen Gross wrote:
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
Reviewed-by: Julien Grall
Although one unrelated comment below
flight 150963 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150963/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 150933
test-amd64-amd64-xl-rtds 18 gues
Hello,
When writing a patch to tools/configure.ac, re-running autogen.sh
resulted in a diff with unexpected changes. Specifically, these additions:
diff --git a/configure b/configure
index 8af54e8a5a..9da3970cef 100755
--- a/configure
+++ b/configure
@@ -644,6 +644,7 @@ infodi
On 10.06.20 19:55, Julien Grall wrote:
Hi Juergen,
On 09/06/2020 16:45, Juergen Gross wrote:
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
Reviewed-by: Julien Gral
I had been working on Xen on the Pi4 by throwing kernels I compiled onto
existing sd cards, and this was working fine. I finally got to a full
yocto build of the system, and it didn't boot.
In fact, Xen didn't print anything at all, and nothing happens that
might suggest it's booting without any
At 15:22 +0200 on 09 Jun (1591716153), Olaf Hering wrote:
> 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: e
flight 150978 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150978/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dafce295e6f447ed8905db4e29241e2c6c2a4389
baseline version:
ovmf 6aa48ab791ecc4fe22d11
Hi Marc,
On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote:
> > I was wondering if you heard about any potential issue with guest EOI
> > not forwarded to the host. This is on TI Keystone (Cortex A-15).
>
> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway
> all run just fine
On Wed, 10 Jun 2020 at 19:49, Jürgen Groß wrote:
>
> On 10.06.20 19:55, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 09/06/2020 16:45, Juergen Gross wrote:
> >> Writing the runtime parameters loglvl or guest_loglvl omits setting the
> >> new length of the resulting parameter value.
> >>
> >> Rep
flight 150970 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150970/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150930
test-amd64-amd64-xl-qemuu-win7-amd6
flight 150991 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150176
build-i386-pre
flight 150997 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150997/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 150932
test-armhf-armhf-libvirt-raw 13 saveresto
flight 151011 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150039
build-i386-pre
On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote:
>
> I had been working on Xen on the Pi4 by throwing kernels I compiled onto
> existing sd cards, and this was working fine. I finally got to a full
> yocto build of the system, and it didn't boot.
>
> In fact, Xen didn't print anything at all
flight 151012 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151012/
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
flight 151013 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 150120
build-i386
errno is reset by subsequent system & library calls, so it may be
inaccurate by the time connect_socket returns. Call perror immediately
after failing system calls to print the proper message.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 7 +--
1 file changed, 5 in
Close open FDs and close th vchan connection when exiting the program.
This addresses some Coverity findings about leaking file descriptors.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/libvchan/vchan-soc
Use a struct to group the vchan ctrl and FDs. This will facilite
tracking the state of open and closed FDs and ctrl in data_loop().
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 52 +
1 file changed, 30 insertions(+), 22 deletions(-)
diff --
The use of perror on the return from listen_socket can produce
misleading results like:
UNIX socket path "/tmp/aaaa" too long (156 >= 108)
listen socket: Success
errno is reset by subsequent system & library calls, so it may be
inaccurate by the time listen_socket returns. Call perror immedia
Switch data_loop to take a pointer to vchan_proxy_state.
No functional change.
This removes a dead store to input_fd identified by Coverity.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 65 +++--
1 file changed, 33 insertions(+), 32 deletions(-
These FDs are closed, so set them to -1 so they are no longer valid.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libvchan/vchan-socket-proxy.c
b/tools/libvchan/vchan-socket-proxy.c
index 29a12260ed..cd7629bc4e
Check the socket path length to ensure sun_path is NUL terminated.
This was spotted by Citrix's Coverity.
Also use strcpy to avoid a warning "'__builtin_strncpy' specified bound
108 equals destination size [-Werror=stringop-truncation]" flagged by
gcc 10.
Signed-off-by: Jason Andryuk
---
CC: Ol
This series addresses some Coverity reports. To handle closing FDs, a
state struct is introduced to track FDs closed in both main() and
data_loop().
v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with
gcc-10. Also, "Move perror() into listen_socket" and "Move perror()
into conne
Introduce 'ret' for main's return value and remove direct returns. This
is in preparation for a unified exit path with resource cleanup.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tool
Check the return value of xs_watch and error out on failure.
This was found by Citrix's Coverity.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/libvchan/vchan-socket-proxy.c
b/tools/lib
input_fd & output_fd may be the same FD. In that case, mark both as -1
when closing one. That avoids a dangling FD reference.
Signed-off-by: Jason Andryuk
---
tools/libvchan/vchan-socket-proxy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libvchan/vchan-socket-proxy.c
b/tools/
The hardcoded tpm_signature is too restrictive to detect many TPMs. For
instance, it doesn't accept a QEMU emulated TPM (VID 0x1014 DID 0x0001).
Make the TPM detection match that in rombios which accepts a wider
range.
With this change, the TPM's TCPA ACPI table is generated and the guest
OS can
69 matches
Mail list logo
