On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
make the version an integer.
On 26.06.2020 17:39, Roger Pau Monne wrote:
> XENMEM_acquire_resource and it's related structure is currently inside
> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
> hypervisor or the toolstack only. This is wrong as the hypercall is
> already being used by the Linux kernel
> -Original Message-
> From: Jürgen Groß
> Sent: 27 June 2020 12:55
> To: Julien Grall ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall
> Subject: Re: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that the
> header is just a reference
>
> On 27.06.20 11:55, Julien
> -Original Message-
> From: Jürgen Groß
> Sent: 27 June 2020 12:54
> To: Julien Grall ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Stefano Stabellini ; Wei Liu
>
> Subject: Re: [PATCH v4 for-4.1
> -Original Message-
> From: Andrew Cooper
> Sent: 26 June 2020 18:01
> To: Xen-devel
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu
> ; Daniel De Graaf ; Paul Durrant
>
> Subject: [PATCH] tools/configure: drop BASH configure variable
>
> This is a weird variable to have in the first p
> -Original Message-
> From: Julien Grall
> Sent: 26 June 2020 18:54
> To: Stefano Stabellini ; p...@xen.org
> Cc: Volodymyr Babchuk ;
> xen-devel@lists.xenproject.org; op-
> t...@lists.trustedfirmware.org
> Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address
>
Hi Xen Dev Community,
I ran into an issue when implementing a prototype for a new paravirtualized
clock for x86-64 hosts. I extended the arch_shared_info struct by 6 fields
totaling at 36 bytes. I updated the xen-foreign/references.size to represent
the new size of the arch_shared_info struct.
On 26.06.2020 19:02, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Daniel De Graaf
Since we've not heard anything from Daniel in quite a while, just
in case:
Acked-by: Jan Beulich
Jan
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 29 June 2020 09:22
> To: Andrew Cooper
> Cc: Xen-devel ; Daniel De Graaf
>
> Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts
>
> On 26.06.2020 19:02, Andrew Cooper wrote:
> > Signed-off-by:
On 27.06.2020 11:55, Julien Grall wrote:
> From: Julien Grall
>
> The specification of pvcalls suggests there is padding for 32-bit x86
> at the end of most the structure. However, they are not described in
> in the public header.
>
> Because of that all the structures would be 32-bit aligned an
On 27.06.2020 10:35, Trevor Bentley wrote:
> Please let me know if you have any suggestions to try, or if you need
> any extra information for debugging.
I don't suppose you have a serial port on this laptop? I ask because
the serial log (and the possibility to issue debug keys) are about
the onl
On 26.06.2020 19:00, Andrew Cooper wrote:
> @@ -24,14 +20,14 @@ extra-y += $(ALL_H_FILES)
>
> mkflask := policy/mkflask.sh
> quiet_cmd_mkflask = MKFLASK $@
> -cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
> +cmd_mkflask = $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
On Sun, Jun 28, 2020 at 08:58:14AM +0200, joshua_pe...@web.de wrote:
> Hello everyone,
>
> I hope this is the right forum for these kinds of questions (the website
> states no "technical support queries"; I'm not sure if this qualifies).
> If not, sorry for the disturbance; just simply direct me e
On Mon, Jun 29, 2020 at 07:43:43AM +, Jan Ruh wrote:
> Hi Xen Dev Community,
>
>
> I ran into an issue when implementing a prototype for a new
> paravirtualized clock for x86-64 hosts. I extended the
> arch_shared_info struct by 6 fields totaling at 36 bytes. I updated
> the xen-foreign/refer
On Sat, Jun 27, 2020 at 08:35:27AM +, Trevor Bentley wrote:
> I asked on #xen on Freenode and was requested to post here.
>
> Summary: Under Xen, both suspend and hibernate operations put the laptop
> into some sort of unrecoverable low-power mode, and a force power-off is
> required.
>
> Env
flight 151444 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151444/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0060e0a694f3f249c3ec081b0e61287c36f64ebb
baseline version:
ovmf 654dc3ed852aafa126e9d
I don't suppose you have a serial port on this laptop? I ask because
the serial log (and the possibility to issue debug keys) are about
the only thing debugging-wise that may help here, short of someone
noticing the underlying problem by code inspection.
Afraid not, it's hyper-modern; just 3 USB
Completely a shot in the dark, but have you tried with legacy boot
(BIOS) instead of UEFI? To try to rule out what might cause the
issues.
From the BIOS: "Legacy Boot mode is not supported on this platform."
This is my punishment for buying a brand new laptop model for Linux...
-Trevor
- 23 cze 2020 o 13:54, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> Overall, the moving parts of this series needs to split out into rather
> more patches.
>
> First, in patch 3, the hvm_funcs.pt_supported isn't the place for that
> to live. You want a global "bool vmtrace_supported"
> Did you try backing up your changes and seeing if the same happens?
If backing up my changes everything works as expected.
> Did you rebuild both the Xen hypervisor and the tools?
Yes, I rebuild both Xen hypervisor and the tools.
> Pasting your xl config file would be helpful in order to help
Hi Roger,
thank you very much for your help. Further replies are inline.
> Gesendet: Montag, 29. Juni 2020 um 10:57 Uhr
> Von: "Roger Pau Monné"
> An: joshua_pe...@web.de
> Cc: xen-devel@lists.xenproject.org
> Betreff: Re: Questions about PVH memory layout
>
> > The other
> > thing is, the first
Hi Jan,
On 29/06/2020 09:28, Jan Beulich wrote:
On 27.06.2020 11:55, Julien Grall wrote:
From: Julien Grall
The specification of pvcalls suggests there is padding for 32-bit x86
at the end of most the structure. However, they are not described in
in the public header.
Because of that all the
On Mon, Jun 29, 2020 at 09:56:43AM +, Jan Ruh wrote:
> > Did you try backing up your changes and seeing if the same happens?
>
> If backing up my changes everything works as expected.
>
> > Did you rebuild both the Xen hypervisor and the tools?
>
> Yes, I rebuild both Xen hypervisor and the
There is no need to automatically disable PV32 support on SHSTK-capable
hardware if Xen isn't actually using the feature.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
For 4.14. Minor bugfix.
---
xen/arch/x86/setup.c | 4
1 file chan
On 29/06/2020 06:17, Jürgen Groß wrote:
> On 26.06.20 19:24, Andy Lutomirski wrote:
>> On Xen PV, SWAPGS doesn't work. Teach __rdfsbase_inactive() and
>> __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV. The Xen
>> pvop code will understand this and issue the correct hypercalls.
>>
>> Cc:
flight 151441 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did no
On 29.06.2020 12:03, Julien Grall wrote:
> On 29/06/2020 09:28, Jan Beulich wrote:
>> On 27.06.2020 11:55, Julien Grall wrote:
>>> As an aside, the padding sadly cannot be mandated to be 0 as they are
>>> already present. So it is not going to be possible to use the padding
>>> for extending a comm
On 29/06/2020 12:22, Jan Beulich wrote:
On 29.06.2020 12:03, Julien Grall wrote:
On 29/06/2020 09:28, Jan Beulich wrote:
On 27.06.2020 11:55, Julien Grall wrote:
As an aside, the padding sadly cannot be mandated to be 0 as they are
already present. So it is not going to be possible to use t
On 29.06.2020 12:31, Andrew Cooper wrote:
> There is no need to automatically disable PV32 support on SHSTK-capable
> hardware if Xen isn't actually using the feature.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 11:31
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ;
> Roger Pau Monné ; Paul Durrant
> Subject: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out
>
> There is no need to automatically di
Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
variable"):
> On 26.06.2020 19:00, Andrew Cooper wrote:
> > diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh
> > b/xen/xsm/flask/policy/mkaccess_vector.sh
> > old mode 100644
> > new mode 100755
> > diff --git a/xen/xsm/fla
On 29/06/2020 09:25, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 29 June 2020 09:22
>> To: Andrew Cooper
>> Cc: Xen-devel ; Daniel De Graaf
>>
>> Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts
>>
>> On 26.06.2
Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure variable"):
> This is a weird variable to have in the first place. The only user of it is
> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts
> run with this are shebang sh anyway, so don't need bash i
On 29/06/2020 14:34, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure
> variable"):
>> This is a weird variable to have in the first place. The only user of it is
>> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two
>> scripts
>> run w
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 14:51
> To: Ian Jackson
> Cc: Xen-devel ; Wei Liu ;
> Daniel De Graaf
> ; Paul Durrant
> Subject: Re: [PATCH] tools/configure: drop BASH configure variable
>
> On 29/06/2020 14:34, Ian Jackson wrote:
> > Andrew Cooper writ
On 29.06.2020 14:05, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
> variable"):
>> On 26.06.2020 19:00, Andrew Cooper wrote:
>>> diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh
>>> b/xen/xsm/flask/policy/mkaccess_vector.sh
>>> old mode 100644
>>>
On Thu, Jun 18, 2020 at 06:05:21PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > Some video BIOS require a PIT in order to work properly, hence classic
> > PV dom0 gets partial access to the physical PIT as long as it's not in
> > use by Xen.
> >
> > Since PVH dom0 is
flight 151454 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151454/
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
On Fri, Jun 26, 2020 at 7:26 AM Ian Jackson wrote:
>
> Wei Liu writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool"):
> > On Mon, Jun 22, 2020 at 08:12:56PM +0200, Michał Leszczyński wrote:
> > > Add an demonstration tool that uses xc_vmtrace_* calls in order
> > > to manage external I
On Sat, 27 Jun 2020, Julien Grall wrote:
> From: Julien Grall
>
> The specification of pvcalls suggests there is padding for 32-bit x86
> at the end of most the structure. However, they are not described in
> in the public header.
>
> Because of that all the structures would be 32-bit aligned an
As was pointed out by "mm: fix public declaration of struct
xen_mem_acquire_resource", we're not currently handling structs
correctly that has uint64_aligned_t fields. #pragma pack(4) suppresses
the necessary alignment even if the type did properly survive (which
it also didn't) in the process of g
On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
> While I've been running into an issue here only because of an additional
> local change I'm carrying, to be able to override just the compiler in
> $(XEN_ROOT)/.config (rather than the whole tool chain), in
> config/StdGNU.mk:
>
> ifeq
On Sun, 28 Jun 2020, Xiaofei Tan wrote:
> Fix the following sparse warning:
>
> arch/arm64/xen/../../arm/xen/enlighten.c:244: warning: macro
> "GRANT_TABLE_PHYSADDR" is not used [-Wunused-macros]
>
> It is an isolated macro, and should be removed when its last user
> was deleted in the following
flight 151451 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151451/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0f01cec52f4794777feb067e4fa0bfcedfdc124e
baseline version:
ovmf 0060e0a694f3f249c3ec0
flight 151445 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
test-amd64-amd64-xl-qemuu-dmrestrict-amd
flight 151448 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151448/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151437
test-amd64-amd64-xl-qemut-win7-amd64
flight 151457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151457/
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
On Fri, 26 Jun 2020, Michael S. Tsirkin wrote:
> On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
>
On Mon, 29 Jun 2020, Peng Fan wrote:
> > > If that is the case, how is it possible that virtio breaks on ARM
> > > using the default dma_ops? The breakage is not Xen related (except
> > > that Xen turns dma_ops on). The original message from Peng was:
> > >
> > > vring_map_one_sg -> vring_use_dma
> Subject: RE: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, 29 Jun 2020, Peng Fan wrote:
> > > > If that is the case, how is it possible that virtio breaks on ARM
> > > > using the default dma_ops? The breakage is not Xen related (except
> > > > that Xen turns dma_ops on). The original mes
On Tue, Jun 16, 2020 at 01:16:10PM -0700, Stefano Stabellini wrote:
> On Mon, 15 Jun 2020, Bobby Eshleman wrote:
> > On Tue, Jun 16, 2020 at 01:10:17AM +, Alistair Francis wrote:
> > > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote:
> > > > Any updates? I am looking forward to this
On Mon, Jun 22, 2020 at 01:43:40PM +0200, Jan Beulich wrote:
> On 22.01.2020 02:59, Bobby Eshleman wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/sysctl.c
> > @@ -0,0 +1,31 @@
> > +/**
> > + * Arch-specific sysctl.c
> >
On Mon, Jun 22, 2020 at 01:38:20PM +0200, Jan Beulich wrote:
> On 22.01.2020 02:58, Bobby Eshleman wrote:
> > From: Alistair Francis
> >
> > Add the lib directory with find_next_bit support.
> >
> > This was taken from Linux
>
> As was Arm64's - the two definitely would want folding.
>
Indeed
flight 151452 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are fa
flight 151459 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151459/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
flight 151465 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151465/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 00217f1919270007d7a911f89b32e39b9dcaa907
baseline version:
ovmf 0f01cec52f4794777feb0
On 6/29/20 10:02 AM, Jürgen Groß wrote:
> On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> 1. Change protocol version from string to integer
>>
>> Version string, which is in fact an integer, is hard to handle in the
>> code that supports different protocol
57 matches
Mail list logo
