flight 161484 xen-4.14-testing real [real]
flight 161498 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161484/
http://logs.test-lab.xenproject.org/osstest/logs/161498/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 28.04.2021 00:00, Scott Davis wrote:
> On 4/27/21, 2:56 AM, Jan Beulich wrote:
>> On 26.04.2021 19:25, Scott Davis wrote:
>>> This patch modifies Xen's behavior when making devices assignable while the
>>> iommu=no-quarantine command line option is in effect. Currently this option
>>> only affec
On 27.04.2021 20:09, Roger Pau Monné wrote:
> On Tue, Apr 27, 2021 at 05:31:25PM +0200, Jan Beulich wrote:
>> On 27.04.2021 16:21, Roger Pau Monne wrote:
>>> Remove the unneeded usage of the compat layer to copy frame pointers
>>> from guest address space. Instead just use raw_copy_from_guest.
>>>
On 27.04.2021 20:07, Roger Pau Monné wrote:
> On Tue, Apr 27, 2021 at 05:37:22PM +0200, Jan Beulich wrote:
>> On 27.04.2021 16:21, Roger Pau Monne wrote:
>>> Remove the unneeded usage of the compat layer to copy frame pointers
>>> from guest address space. Instead just use raw_copy_from_guest.
>>>
flight 161485 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161485/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b90b8abb4049e2d98040f548ad23b6ab22d5d19
baseline version:
ovmf 8d2012035db3cb869d1da
flight 161481 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161481/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
flight 161480 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 161470
Tests which did no
Thanks for the feedback, Jan!
On 4/27/21, 2:56 AM, Jan Beulich wrote:
> On 26.04.2021 19:25, Scott Davis wrote:
>> This patch modifies Xen's behavior when making devices assignable while the
>> iommu=no-quarantine command line option is in effect. Currently this option
>> only affects device deass
flight 161478 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161478/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161476 xen-4.12-testing real [real]
flight 161488 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161476/
http://logs.test-lab.xenproject.org/osstest/logs/161488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 27/04/2021 08:09, Jan Beulich wrote:
> On 26.04.2021 14:45, Andrew Cooper wrote:
>> ... rather than having separate definitions locally. EXC_HAS_EC in
>> particular
>> is missing #CP, #VC and #SX vs X86_EXC_HAVE_EC.
>>
>> Also switch a raw 14 for X86_EXC_PF in x86_emul_pagefault().
>>
>> No fu
On Tue, Apr 27, 2021 at 05:31:25PM +0200, Jan Beulich wrote:
> On 27.04.2021 16:21, Roger Pau Monne wrote:
> > Remove the unneeded usage of the compat layer to copy frame pointers
> > from guest address space. Instead just use raw_copy_from_guest.
> >
> > While there change the accessibility check
On Tue, Apr 27, 2021 at 05:37:22PM +0200, Jan Beulich wrote:
> On 27.04.2021 16:21, Roger Pau Monne wrote:
> > Remove the unneeded usage of the compat layer to copy frame pointers
> > from guest address space. Instead just use raw_copy_from_guest.
> >
> > While there change the accessibility check
On 27/04/2021 14:18, Jan Beulich wrote:
> On 27.04.2021 15:02, Andrew Cooper wrote:
>> This is pure obfuscation (in particular, hiding the two locations where the
>> variable gets set), and is longer than the code it replaces.
> Obfuscation - not just; see below.
>
>> Also fix MACH2PHYS_COMPAT_VIRT
Now (postgresql 11) this prints a bunch of COPY notices. Suppress
them with a -q.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index df83b65a..357646bb 100755
--- a/mg
The dump now (postgresql 11) contains lots of "public." which made
these regexps not match.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index b49fbecf..b5906d70 1
With -qff it now complains, daftly, that -q doesn't take a value.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index b5906d70..26e35c5b 100755
--- a/mg-schema-test-data
This data doesn't really survive, since the tasks are all mangled.
Rather than trying to transpose it, just don't transfer it for now.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 1 +
1 file changed, 1 insertion(+)
diff --git a/mg-schema-test-database b/mg-schema-test-database
inde
Now (postgresql 11):
* psql transaction behaviour has changed so that now we want to
use the -1 option. This obviates a few BEGIN and COMMITs.
* SET implicitly starts a transaction and DROP and CREATE DATABASE
aren't transactional and now complain if they are run in a
transaction. So
Now (postgresql 11) start_value is in a different table. We don't
really care about it very much and mostly care about the last value,
so we fix that (and launder the for-db comparison dumps).
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 16
1 file changed, 12 inser
Evidently it has been a while since I last ran this script since
it really didn't work at all. Fix it.
Ian Jackson (7):
mg-schema-test-database: posgtres compat: psql transactions
mg-schema-test-database: Be slightly more defensive
mg-schema-test-database: posgtres compat: Cope with schema
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
index e69b9881..b49fbecf 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -381,7 +381,8 @@ END
On 27/04/2021 16:53, Jan Beulich wrote:
> On 26.04.2021 19:54, Andrew Cooper wrote:
>> On CET-capable hardware, VMRUN/EXIT unconditionally swaps S_SET, SSP and
> Nit: S_CET?
Ah yes.
>
>> ISST (subject to cleanbits) without further settings.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beul
On 27/04/2021 16:47, Jan Beulich wrote:
> On 26.04.2021 19:54, Andrew Cooper wrote:
>> For now, let VMs opt into using CET by setting cet_ss/ibt in the CPUID
>> policy. Also extend cr4 handling to permit CR4.CET being set, along with
>> logic to interlock CR4.CET and CR0.WP.
>>
>> Everything else
On 27/04/2021 13:54, Jan Beulich wrote:
> In order for a to-be-introduced ERMS form of memcpy() to not regress
> boot performance on certain systems when video output is active, we
> first need to arrange for avoiding further dependency on firmware
> setting up MTRRs in a way we can actually furthe
On Tue, Apr 27, 2021 at 05:28:30PM +0100, Julien Grall wrote:
> On 27/04/2021 17:04, Anthony PERARD wrote:
> > On Mon, Apr 05, 2021 at 04:57:06PM +0100, Julien Grall wrote:
> > > struct cmd_spec {
> > > -char *cmd_name;
> > > +const char *cmd_name;
> > > int (*cmd_impl)(int argc, ch
Hi Anthony,
On 27/04/2021 17:04, Anthony PERARD wrote:
On Mon, Apr 05, 2021 at 04:57:06PM +0100, Julien Grall wrote:
From: Julien Grall
literal strings are not meant to be modified. So we should use const
char * rather than char * when we want to store a pointer to them.
Signed-off-by: Julie
On 27/04/2021 16:56, Jan Beulich wrote:
> On 26.04.2021 19:54, Andrew Cooper wrote:
>> VT-x has separate entry/exit control for loading guest/host state. Saving
>> guest state on vmexit is performed unconditionally.
> With the latter I find ...
>
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/a
flight 161483 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161483/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
and cmdtable_len.
The entries in cmd_table don't need to be modified once xl is running.
Signed-off-by: Anthony PERARD
---
tools/xl/xl.c | 4 ++--
tools/xl/xl.h | 6 +++---
tools/xl/xl_cmdtable.c | 8
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tool
On 15.04.2021 11:27, Jan Beulich wrote:
> This combination doesn't really make sense (and there likely are more);
> in particular even if the code built with both options set, HVM guests
> wouldn't work (and I think one wouldn't be able to create one in the
> first place). The alternative here woul
On Mon, Apr 05, 2021 at 04:57:06PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> Signed-off-by: Julien Grall
> ---
> diff --git a/tools/xl/xl.h b/t
On 07.04.2021 11:56, Jan Beulich wrote:
> Our releases look to flip-flop between keeping or discarding the date
> and title of the referenced qemu-trad commit. I think with the hash
> replaced by a tag, the commit's date and title would better also be
> purged.
>
> Signed-off-by: Jan Beulich
> --
On 26.04.2021 18:21, Rahul Singh wrote:
> Move iommu_update_ire_from_msi(..) from passthrough/pci.c to
> xen/iommu.h and wrap it under CONFIG_X86 as it is referenced in x86
> code only to avoid compilation error for other architecture when
> HAS_PCI is enabled.
>
> No functional change intended.
>
On 26.04.2021 19:54, Andrew Cooper wrote:
> VT-x has separate entry/exit control for loading guest/host state. Saving
> guest state on vmexit is performed unconditionally.
With the latter I find ...
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -2014,6 +2014,9 @@ v
On 26.04.2021 19:54, Andrew Cooper wrote:
> On CET-capable hardware, VMRUN/EXIT unconditionally swaps S_SET, SSP and
Nit: S_CET?
> ISST (subject to cleanbits) without further settings.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
with one question:
> @@ -497,7 +501,9 @@ struct vmcb
On 26.04.2021 19:54, Andrew Cooper wrote:
> For now, let VMs opt into using CET by setting cet_ss/ibt in the CPUID
> policy. Also extend cr4 handling to permit CR4.CET being set, along with
> logic to interlock CR4.CET and CR0.WP.
>
> Everything else will malfunction for now, but this will help a
On 27.04.2021 16:21, Roger Pau Monne wrote:
> Remove the unneeded usage of the compat layer to copy frame pointers
> from guest address space. Instead just use raw_copy_from_guest.
>
> While there change the accessibility check of one frame_head beyond to
> be performed as part of the copy, like i
On 27.04.2021 16:21, Roger Pau Monne wrote:
> Remove the unneeded usage of the compat layer to copy frame pointers
> from guest address space. Instead just use raw_copy_from_guest.
>
> While there change the accessibility check of one frame_head beyond to
> be performed as part of the copy, like i
flight 161475 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Fri, Dec 18, 2020 at 01:32:33PM -0800, Elliott Mitchell wrote:
> With libxl having gotten a lot more constant, now printf_info_sexp() and
> printf_info_one_json() can add consts. May not be particularly
> important, but it is best to mark things constant when they are known to
> be so.
>
> Sig
On Fri, Dec 18, 2020 at 01:37:44PM -0800, Elliott Mitchell wrote:
> Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be
> examining the pointed to thing, not modifying it. This potentially
> results in higher-performance output. This also allows spreading
> constants further, al
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
While there change the accessibility check of one frame_head beyond to
be performed as part of the copy, like it's done in the Linux code.
Note it's unclear why this
On Tue, Apr 27, 2021 at 03:40:24PM +0200, Jan Beulich wrote:
> On 27.04.2021 15:31, Roger Pau Monné wrote:
> > On Tue, Apr 27, 2021 at 02:30:35PM +0200, Jan Beulich wrote:
> >> On 27.04.2021 11:05, Roger Pau Monné wrote:
> >>> On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
> On 2
On 27.04.2021 15:49, Andrew Cooper wrote:
> On 27/04/2021 13:56, Jan Beulich wrote:
>
> The grammar in the subject is very awkward. The (not just) like that is
> weird.
>
> If it were me, I'd phrase this as "minor adjustments to command line
> handling".
Well, the (not just) is intentionally th
On 27/04/2021 14:57, Jan Beulich wrote:
diff --git a/docs/hypercall-interfaces/arm64/grant_tables.rst
b/docs/hypercall-interfaces/arm64/grant_tables.rst
new file mode 100644
index 00..8955ec5812
--- /dev/null
+++ b/docs/hypercall-interfaces/arm64/grant_tables.rst
@@ -0,0 +1,8 @@
+.. SPDX
On 26.04.2021 17:37, Luca Fancellu wrote:
> --- a/docs/hypercall-interfaces/arm64.rst
> +++ b/docs/hypercall-interfaces/arm64.rst
> @@ -8,6 +8,7 @@ Starting points
> .. toctree::
> :maxdepth: 2
>
> + arm64/grant_tables
>
>
> Functions
> diff --git a/docs/hypercall-interfaces/arm64/gra
On 27/04/2021 13:56, Jan Beulich wrote:
The grammar in the subject is very awkward. The (not just) like that is
weird.
If it were me, I'd phrase this as "minor adjustments to command line
handling".
> Document both options. Add section annotations to both variables holding
> the parsed values a
On 27.04.2021 15:31, Roger Pau Monné wrote:
> On Tue, Apr 27, 2021 at 02:30:35PM +0200, Jan Beulich wrote:
>> On 27.04.2021 11:05, Roger Pau Monné wrote:
>>> On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
On 20.04.2021 18:20, Roger Pau Monné wrote:
> On Tue, Apr 20, 2021 at 0
On Tue, Apr 27, 2021 at 02:30:35PM +0200, Jan Beulich wrote:
> On 27.04.2021 11:05, Roger Pau Monné wrote:
> > On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
> >> On 20.04.2021 18:20, Roger Pau Monné wrote:
> >>> On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote:
> On 2
On 27/04/2021 13:56, Jan Beulich wrote:
> Now that we use ioremap_wc() for mapping the frame buffer, there's no
> need for this option anymore. As noted in the change introducing the
> use of ioremap_wc(), mtrr_add() didn't work in certain cases anyway.
>
> Signed-off-by: Jan Beulich
Acked-by: An
On 27/04/2021 13:53, Jan Beulich wrote:
> Unlike Linux, Xen has never (so far) used alternatives patching for
> memcpy() or memset(), even less such utilizing multiple alternatives.
> Correct the Linux-inherited comment to match reality.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 27.04.2021 15:02, Andrew Cooper wrote:
> This is pure obfuscation (in particular, hiding the two locations where the
> variable gets set), and is longer than the code it replaces.
Obfuscation - not just; see below.
> Also fix MACH2PHYS_COMPAT_VIRT_START to be expressed as a 1-parameter macro,
Hello everyone,
https://design-sessions.xenproject.org is now open for registration and topic
submissions.
Anyone can register and submit sessions, but new accounts start out as
“unverified” until manually verified, or a verification code (sent before the
summit to registered attendees) is ent
flight 161477 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161477/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8d2012035db3cb869d1da8a95c1308025cadbeee
baseline version:
ovmf 5396354b868bd6652600a
This is pure obfuscation (in particular, hiding the two locations where the
variable gets set), and is longer than the code it replaces.
Also fix MACH2PHYS_COMPAT_VIRT_START to be expressed as a 1-parameter macro,
which is how it is used. The current construct only works because
HYPERVISOR_COMPAT
Document both options. Add section annotations to both variables holding
the parsed values as well as a few adjacent ones. Adjust the types of
font_height and vga_compat.
Signed-off-by: Jan Beulich
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2369,9 +2369,2
Now that we use ioremap_wc() for mapping the frame buffer, there's no
need for this option anymore. As noted in the change introducing the
use of ioremap_wc(), mtrr_add() didn't work in certain cases anyway.
Signed-off-by: Jan Beulich
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,9 @@ The for
There's no point in keeping the VA space occupied when no further output
will occur.
Signed-off-by: Jan Beulich
--- a/xen/drivers/video/lfb.c
+++ b/xen/drivers/video/lfb.c
@@ -168,4 +168,5 @@ void lfb_free(void)
xfree(lfb.lbuf);
xfree(lfb.text_buf);
xfree(lfb.line_len);
+lfb.l
Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.
Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.
In order for a to-be-introduced ERMS form of memcpy() to not regress
boot performance on certain systems when video output is active, we
first need to arrange for avoiding further dependency on firmware
setting up MTRRs in a way we can actually further modify. On many
systems, due to the continuous
Unlike Linux, Xen has never (so far) used alternatives patching for
memcpy() or memset(), even less such utilizing multiple alternatives.
Correct the Linux-inherited comment to match reality.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -194,8 +
While the performance varies quite a bit on older (pre-ERMS) and
newer (ERMS) hardware, so far we've been going with just a single
flavor of these two functions, and oddly enough with ones not
consistent with one another. Using plain memcpy() / memset() on
MMIO (video frame buffer) is generally oka
On 27.04.2021 11:05, Roger Pau Monné wrote:
> On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
>> On 20.04.2021 18:20, Roger Pau Monné wrote:
>>> On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote:
On 20.04.2021 17:29, Roger Pau Monné wrote:
> On Thu, Apr 01, 2021 at 1
If PATH_MAX is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror.
Signed-off-by: Costin Lupu
---
tools/libfsimage/ext2fs/fsys_ext2fs.c | 2 ++
tools/libfsimage/reiserfs/fsys_reiserfs.c | 2 ++
2 files changed, 4
If PAGE_SIZE is already defined in the system (e.g. in
/usr/include/limits.h header) then gcc will trigger a redefinition error
because of -Werror. This commit also protects PAGE_SHIFT and PAGE_MASK
definitions for keeping consistency.
Same issue applies for redefinitions of Val_none and Some_val
If PAGE_SIZE is already defined in the system (e.g. in
/usr/include/limits.h header) then gcc will trigger a redefinition error
because of -Werror. This commit also protects PAGE_SHIFT and PAGE_MASK
definitions for keeping consistency.
Signed-off-by: Costin Lupu
---
tools/libs/gnttab/linux.c | 6
If PAGE_SIZE is already defined in the system (e.g. in
/usr/include/limits.h header) then gcc will trigger a redefinition error
because of -Werror. This commit also protects PAGE_SHIFT and PAGE_MASK
definitions for keeping consistency.
Signed-off-by: Costin Lupu
---
tools/libs/foreignmemory/priv
If PAGE_SIZE is already defined in the system (e.g. in
/usr/include/limits.h header) then gcc will trigger a redefinition error
because of -Werror. This commit also protects PAGE_SHIFT definitions for
keeping consistency.
Signed-off-by: Costin Lupu
---
tools/debugger/kdd/kdd-xen.c | 4
tool
For replication I used gcc 10.3 on an Alpine system. In order to replicate the
redefinition error for PAGE_SIZE one should install the 'fortify-headers'
package which will change the chain of included headers by indirectly including
/usr/include/limits.h where PAGE_SIZE and PATH_MAX are defined.
C
On Mon, Apr 26, 2021 at 09:49:13AM +0200, Jan Beulich wrote:
> On 23.04.2021 16:37, Roger Pau Monne wrote:
> > Remove the unneeded usage of the compat layer to copy frame pointers
> > from guest address space. Instead just use raw_copy_from_guest.
> >
> > While there drop the checks for the access
flight 161472 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
Hi Michal,
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when rea
On Tue, Apr 27, 2021 at 12:40:03PM +0200, Roger Pau Monne wrote:
> When trying to build an hypervisor without PV or HVM (ie: using
> automation/configs/x86/no_hvm_pv_config) it fails to link with:
>
> prelink.o: In function `sh_remove_write_access_from_sl1p':
> arch/x86/mm/shadow/common.c:(.text+0
Does anyone happen to know why libxl__wait_device_connection (via
libxl__ev_time_register_rel) uses absolute time values, instead of relative
monotonic times, to wait for the expected state changes?
I think this can easily confuse libxl when the system time is corrected by some
ntp daemon while
When trying to build an hypervisor without PV or HVM (ie: using
automation/configs/x86/no_hvm_pv_config) it fails to link with:
prelink.o: In function `sh_remove_write_access_from_sl1p':
arch/x86/mm/shadow/common.c:(.text+0x72b4c): undefined reference to
`sh_rm_write_access_from_sl1p__guest_4'
ar
On 27/04/2021 07:46, Jan Beulich wrote:
> On 26.04.2021 19:54, Andrew Cooper wrote:
>> Some initial pieces for guest support. Everything will currently malfunction
>> for VMs which explicitly opt in to CET_SS/IBT.
>>
>> Still TODO as a minimum:
>> * Teach the pagewalk logic about shadow stack acc
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysr
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysr
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysr
Hi Michal,
On 27/04/2021 10:35, Michal Orzel wrote:
... as it is never used even in the patch introducing it.
Signed-off-by: Michal Orzel
Acked-by: Julien Grall
Cheers,
---
xen/include/asm-arm/gic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-ar
Hi Michal,
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when rea
Hi Michal,
On 27/04/2021 10:35, Michal Orzel wrote:
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when rea
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
... as it is never used even in the patch introducing it.
Signed-off-by: Michal Orzel
---
xen/include/asm-arm/gic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index ad0f7452d0..5069ab4aac 100644
--- a/xen/include/asm-
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
The purpose of this patch series is to remove usage of 32bit helper
macros READ/WRITE_SYSREG32 on arm64 as the idea of them is
not following the latest ARMv8 specification and mrs/msr instructions
are expecting 64bit values.
According to ARM DDI 0487G.a all the AArch64 system registers
are 64bit wi
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32
On Wed, Apr 21, 2021 at 04:09:03PM +0200, Jan Beulich wrote:
> On 20.04.2021 18:20, Roger Pau Monné wrote:
> > On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote:
> >> On 20.04.2021 17:29, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote:
> @@ -
From: Lai Jiangshan
There is no any functionality change intended. Just rename it and
move it to arch/x86/kernel/nmi.c so that we can resue it later in
next patch for early NMI and kvm.
Cc: Thomas Gleixner
Cc: Paolo Bonzini
Cc: Sean Christopherson
Cc: Steven Rostedt
Cc: Andi Kleen
Cc: Andy
On 19.03.2021 13:14, Dario Faggioli wrote:
> If we schedule, and the current vCPU continues to run, its statistical
> load is not properly updated, resulting in something like this, even if
> all the 8 vCPUs are 100% busy:
>
> (XEN) Runqueue 0:
> (XEN) [...]
> (XEN) aveload= 2097152
On 27/04/2021 08:16, Michal Orzel wrote:
Hi Jilien,
Hi,
On 21.04.2021 21:16, Julien Grall wrote:
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of h
flight 161470 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161470/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161460
test-armhf-armhf-libvirt 16 save
1 - 100 of 102 matches
Mail list logo
