flight 149198 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 11 guest-start fail REGR. vs. 133580
Tests which did not
On 30.03.2020 21:21, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, copy_to_guest_offset() will allow the hypervisor to copy
> data to guest handle marked const.
>
> Thankfully, no users of the helper will do that. Rather than hoping this
> can be caught during review, harden copy_t
On 30.03.2020 21:21, Julien Grall wrote:
> From: Julien Grall
>
> The fields set_parameter.params and debug.keys should never be modified
> by the hypervisor. So mark them as const.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
> I am not entirely sure whether we should bump the s
On 17.03.2020 16:23, Paul Durrant wrote:
> That looks like it will do the job. I'll see if I can get it tested.
Any luck with this, yet?
Jan
On 30.03.2020 08:54, Alexandru Isaila wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
> This is done by having a
On 30.03.2020 15:18, Wei Liu wrote:
> On Mon, Mar 30, 2020 at 05:53:08PM +0530, Simran Singhal wrote:
>> Compress two lines into a single line if immediate return statement is found.
>> It also remove variables retval, freq, effective, vector, ovf and now
>> as they are no longer needed.
>>
>> Sign
On 31.03.2020 10:43, Jan Beulich wrote:
On 30.03.2020 08:54, Alexandru Isaila wrote:
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
t
On 31.03.2020 09:54, Isaila Alexandru wrote:
>
>
> On 31.03.2020 10:43, Jan Beulich wrote:
>> On 30.03.2020 08:54, Alexandru Isaila wrote:
>>> At this moment a guest can call vmfunc to change the altp2m view. This
>>> should be limited in order to avoid any unwanted view switch.
>>>
>>> The new x
flight 149207 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149207/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3000c2963db319d055f474c394b062af910bbb2f
baseline version:
ovmf d671d1fa48dbb3f22b68c
The first patch definitely needs backporting. Second is a good candidate as
well. Everything else probably not.
This follows similar cleanup on the Intel side, removing gratuitous memory
allocations (both interms of number, and indirection), and fixes several
things to be more uniform (handling
We currently copy the entire equivalency table, and the single correct
microcode. This is not safe to heterogeneous scenarios, and as Xen doesn't
support such situations to being with, can be used to simplify things further.
The CPUID.1.EAX => processor_rev_id mapping is fixed for an individual p
To simplify future cleanup, rename this variable.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x
cpu_request_microcode() doesn't know the buffer is at least 4 bytes long
before inspecting UCODE_MAGIC.
install_equiv_cpu_table() doesn't know the boundary of the buffer it is
interpreting as an equivalency table. This case was clearly observed at one
point in the past, given the subsequent overr
The microcode revision of whichever CPU runs cpu_request_microcode() is not
necessarily applicable to other CPUs.
If the BIOS left us with asymmetric microcode, rejecting updates in
cpu_request_microcode() would prevent us levelling the system even if only up
to the final level. Also, failing to
All code works fine with it having its correct type, and it even allows us to
drop two casts in a printk().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 5 ++---
1 file changed, 2 insertions(+),
Although it is logically a step in the wrong direction overall, it simplifies
the rearranging of cpu_request_microcode() substantially for microcode_fits()
to take struct microcode_header_amd directly, and not require an intermediate
struct microcode_amd pointing at it.
Make this change (taking ti
... rather than collecting it repeatedly in microcode_fits(). This brings the
behaviour in line with the Intel side.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 11 +++
xen/include/asm-x86/microcode.h | 2 +
Just as on the Intel side, there is no point having
get_ucode_from_buffer_amd() make $N memory allocations and free $N-1 of them.
Delete get_ucode_from_buffer_amd() and rewrite the loop in
cpu_request_microcode() to have 'saved' point into 'buf' until we finally
decide to duplicate that blob and r
We only stash the microcode blob size so it can be audited in
microcode_fits(). However, the patch size check depends only on the CPU
family.
Move the check earlier to when we are parsing the container, which avoids
caching bad microcode in the first place, and allows us to avoid storing the
size
Hi,
On 30/03/2020 16:02, Tamas K Lengyel wrote:
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation
With all the necessary cleanup now in place, fold struct microcode_header_amd
into struct microcode_patch and drop the struct microcode_amd temporary
ifdef-ary.
This removes the memory allocation of struct microcode_amd which is a single
pointer to a separately allocated object, and therefore a wa
cpu_request_microcode() is still a confusing mess to follow, with sub
functions responsible for maintaining offset. Rewrite it so all container
structure handling is in this one function.
Rewrite struct mpbhdr as struct container_equiv_table to aid parsing. Drop
container_fast_forward() entirely
This patch start to use if_changed introduced in a previous commit.
Whenever if_changed is called, the target must have FORCE as
dependency so that if_changed can check if the command line to be
run has changed, so the macro $(real-prereqs) must be used to
discover the dependencies without "FORCE"
This start explainning the variables that can be used in the many
Makefiles in xen/.
Most of the document copies and modifies text from Linux v5.4 document
linux.git/Documentation/kbuild/makefiles.rst. Modification are mostly
to avoid mentioning kbuild. Thus I've added the SPDX tag which was
only
We are going to generate the CFLAGS early from "xen/Makefile" instead
of in "Rules.mk", but we need to include "config/auto.conf", so
include it in "Makefile".
Before including "config/auto.conf" we check which make target a user
is calling, as some targets don't need "auto.conf". For targets that
The if_changed macro from Linux, in addition to check if any files
needs an update, check if the command line has changed since the last
invocation. The latter will force a rebuild if any options to the
executable have changed.
if_changed_rule checks dependencies like if_changed, but execute
rule_
Hi Jim,
On 26/03/2020 16:55, Jim Fehlig wrote:
On 3/25/20 1:11 AM, Jan Beulich wrote:
On 24.03.2020 19:39, Julien Grall wrote:
On 24/03/2020 16:13, Jan Beulich wrote:
On 24.03.2020 16:21, Hongyan Xia wrote:
From: Hongyan Xia
In contrast,
after dropping that commit, parallel domain destructi
Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it. The
only flags left to be generated are the ones that depend on the
targets, but the variab
arm*/head.o isn't in obj-y or extra-y, so make don't load the
associated .*.d file (or .*.cmd file when if_changed will be used).
There is a workaround where .*.d file is added manually into DEPS.
Changing DEPS isn't needed, we can simply add head.o into extra-y and
the dependency files will be lo
In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and flags intended for one target
(like -D__OBJECT_FILE__ a
At the moment, early printk can only be configured on the make command
line. It is not very handy because a user has to remove the option
everytime it is using another command other than compiling the
hypervisor.
Furthermore, early printk is one of the few odds one that are not
using Kconfig.
So
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v4
v4:
- some patch already applied.
- Have added patches from "xen/arm: Configure early printk via Kconfig" series.
- Some new patch to add documentation or fix issues,
We are going to move the generation of the early printk macro into
Kconfig. This means all macro will be prefix with CONFIG_. We do that
ahead of the change.
We also take the opportunity to better name some variables, which are
used by only one driver and wouldn't make sens for other UART driver.
Replace a mix of shell script and python script by all python script.
Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
linemarkers generated by the preprocessor. But adding -P inhibit there
generation, thus the grep isn't needed anymore.
gcc -E -P and clang -E -P have different beha
Improvement are:
- give the path to xlat.lst as argument
- include `grep -v` in compat-build-source.py script, we don't need to
write this in several scripted language.
- have 'xlat.lst' path as a variable.
No changes in final compat/%.h headers.
Signed-off-by: Anthony PERARD
---
Notes:
v
Use $(dot-target) to have the target name prefix with a dot.
Now, when the CC command has run, it is recorded in .*.cmd
file, then if_changed_rules will compare it on subsequent runs.
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
xen/Rules.mk | 26 +-
1 fil
In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.
We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.
Change made to the command line:
- Use of $(CPP) instead of $(CC) -E
- Remov
We want to use the same rune to build mm/*/guest_*.o as the one use to
build every other *.o object. The consequence it that file symbols that
the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
(1) Currently we have those two file symbols:
guest_walk.c
guest_walk_2.
In the case where $(obj-y) is empty, we also replace $(c_flags) by
$(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
make trying to include %.h file in the ld command if $(obj-y) isn't
empty anymore on a second run.
Signed-off-by: Anthony PERARD
---
Notes:
v4:
- Have
Both script mkflask.sh and mkaccess_vector.sh generates multiple
files. Exploits the 'multi-target pattern rule' trick to call each
scripts only once.
Signed-off-by: Anthony PERARD
---
Notes:
v4:
- new patch
xen/xsm/flask/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
Use if_changed for building all guest_%.o objects, and make use of
command that already exist.
This patch make a change to the way guest_%.o files are built, and now
run the same commands that enforce unique symbols. But with patch
"xen,symbols: rework file symbols selection", ./symbols should sti
We change the dependencies of prelink-efi.o so that we can use the
same command line. The dependency on efi/built_in.o isn't needed
because, we already have:
efi/*.o: efi/built_in.o
to build efi/*.o files that prelink-efi.o needs.
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
Ac
flight 149200 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which d
On 28.03.2020 12:01, Wei Liu wrote:
> On Fri, Mar 27, 2020 at 07:05:44PM +, Julien Grall wrote:
>> From: Julien Grall
>>
>> bad_ioapic_register() is return a bool, so we should switch to
>> true/false.
>
> is return -> returns / is returning
>
>>
>> Signed-off-by: Julien Grall
>
> Reviewed
On 30.03.2020 12:37, Roger Pau Monné wrote:
> On Fri, Mar 27, 2020 at 07:05:45PM +, Julien Grall wrote:
>> From: Julien Grall
>>
>> The function init_ioapic_mappings() is doing more than initialization
>> mappings. It is also initialization the number of IRQs/GSIs supported.
>>
>> So rename th
flight 149240 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149240/
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
Julien Grall writes ("[PATCH 3/8] tools/libxc: misc: Mark const the parameter
'keys' of xc_send_debug_keys()"):
> From: Julien Grall
>
> OCaml is using a string to describe the parameter 'keys' of
> xc_send_debug_keys(). Since Ocaml 4.06.01, String_val() will return a
> const char * when using -
Julien Grall writes ("[PATCH 4/8] tools/libxc: misc: Mark const the parameter
'params' of xc_set_parameters()"):
> From: Julien Grall
>
> The parameter 'params' of xc_set_parameters() should never be modified.
> So mark it as const.
Reviewed-by: Ian Jackson
Julien Grall writes ("[PATCH 0/8] Fix build with using OCaml 4.06.1 and
-safe-string"):
> This series is meant to solve the build issue reported by Dario when
> using recent version of OCaml and -safe-string.
Thanks. I have reviewed the C tools parts here. I think the ocaml
parts ought to have
On 27.03.2020 20:05, Julien Grall wrote:
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2537,34 +2537,25 @@ static __init bool bad_ioapic_register(unsigned int
> idx)
> return false;
> }
>
> -void __init init_ioapic(void)
> +static void __init init_ioapic_mappings(void
> -Original Message-
> From: Jan Beulich
> Sent: 31 March 2020 08:41
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Varad Gautam' ; 'Julien
> Grall' ;
> 'Roger Pau Monné' ; 'Andrew Cooper'
>
> Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
> shared
Hi Jan,
On 31/03/2020 12:22, Jan Beulich wrote:
On 27.03.2020 20:05, Julien Grall wrote:
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2537,34 +2537,25 @@ static __init bool bad_ioapic_register(unsigned int idx)
return false;
}
-void __init init_ioapic(void)
+static
On 19.03.2020 22:21, David Woodhouse wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -422,7 +422,7 @@ long arch_do_domctl(
> if ( page->u.inuse.type_info & PGT_pinned )
> type |= XEN_DOMCTL_PFINFO_LPINTAB;
>
> -if ( pag
On 19.03.2020 22:21, David Woodhouse wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -491,7 +491,8 @@ void share_xen_page_with_guest(struct page_info *page,
> struct domain *d,
>
> page_set_owner(page, d);
> smp_wmb(); /* install valid domain ptr before updating refcnt.
On 31.03.2020 13:51, Julien Grall wrote:
> Hi Jan,
>
> On 31/03/2020 12:22, Jan Beulich wrote:
>> On 27.03.2020 20:05, Julien Grall wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -2537,34 +2537,25 @@ static __init bool bad_ioapic_register(unsigned int
>>> idx)
>>>
On 16.03.2020 14:41, Andrew Cooper wrote:
> On 16/03/2020 11:00, Jan Beulich wrote:
>> The involved comparison was, very likely inadvertently, converted from
>>> = to > when making changes unrelated to the actual family range.
>>
>> Fixes: 9841eb71ea87 ("x86/cpuid: Drop a guests cached x86 family a
> -Original Message-
> From: Jan Beulich
> Sent: 31 March 2020 13:16
> To: Paul Durrant
> Cc: Andrew Cooper ;
> xen-devel@lists.xenproject.org; Wei Liu ;
> Roger Pau Monné
> Subject: Ping²: [PATCH] x86/HVM: fix AMD ECS handling for Fam 10
>
> On 16.03.2020 14:41, Andrew Cooper wrote:
>
On 27.03.2020 13:28, Andrew Cooper wrote:
> cpu_request_microcode() needs to scan its container and duplicate one blob,
> but the get_next_ucode_from_buffer() helper duplicates every blob in turn.
> Furthermore, the length checking is only safe from overflow in 64bit builds.
>
> Delete get_next_uc
On 31/03/2020 15:09, Jan Beulich wrote:
> On 27.03.2020 13:28, Andrew Cooper wrote:
>> cpu_request_microcode() needs to scan its container and duplicate one blob,
>> but the get_next_ucode_from_buffer() helper duplicates every blob in turn.
>> Furthermore, the length checking is only safe from over
On 27.03.2020 13:29, Andrew Cooper wrote:
> @@ -160,93 +153,85 @@ static int collect_cpu_info(struct cpu_signature *csig)
> return 0;
> }
>
> -static int microcode_sanity_check(const struct microcode_patch *mc)
> +/*
> + * Sanity check a blob which is expected to be a microcode patch. The
On 27.03.2020 13:29, Andrew Cooper wrote:
> With all the necessary cleanup now in place, fold struct
> microcode_header_intel into struct microcode_patch and drop the struct
> microcode_intel temporary ifdef-ary.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulic
On 31/03/2020 15:18, Jan Beulich wrote:
> On 27.03.2020 13:29, Andrew Cooper wrote:
>> @@ -160,93 +153,85 @@ static int collect_cpu_info(struct cpu_signature *csig)
>> return 0;
>> }
>>
>> -static int microcode_sanity_check(const struct microcode_patch *mc)
>> +/*
>> + * Sanity check a blob
On 31.03.2020 12:05, Andrew Cooper wrote:
> The microcode revision of whichever CPU runs cpu_request_microcode() is not
> necessarily applicable to other CPUs.
>
> If the BIOS left us with asymmetric microcode, rejecting updates in
> cpu_request_microcode() would prevent us levelling the system ev
On 31.03.2020 12:05, Andrew Cooper wrote:
> All code works fine with it having its correct type, and it even allows us to
> drop two casts in a printk().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 31.03.2020 12:05, Andrew Cooper wrote:
> ... rather than collecting it repeatedly in microcode_fits(). This brings the
> behaviour in line with the Intel side.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 31.03.2020 12:05, Andrew Cooper wrote:
> We currently copy the entire equivalency table, and the single correct
> microcode. This is not safe to heterogeneous scenarios, and as Xen doesn't
> support such situations to being with, can be used to simplify things further.
s/being/begin/ ?
> The
On 31.03.2020 12:05, Andrew Cooper wrote:
> We only stash the microcode blob size so it can be audited in
> microcode_fits(). However, the patch size check depends only on the CPU
> family.
>
> Move the check earlier to when we are parsing the container, which avoids
> caching bad microcode in th
On 31.03.2020 12:05, Andrew Cooper wrote:
> Although it is logically a step in the wrong direction overall, it simplifies
> the rearranging of cpu_request_microcode() substantially for microcode_fits()
> to take struct microcode_header_amd directly, and not require an intermediate
> struct microcod
On 31.03.2020 12:05, Andrew Cooper wrote:
> To simplify future cleanup, rename this variable.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
> @@ -438,7 +437,7 @@ static struct microcode_patch
> *cpu_request_microcode(const void *buf,
> unsigned int cpu
On 31/03/2020 15:41, Jan Beulich wrote:
> On 31.03.2020 12:05, Andrew Cooper wrote:
>> To simplify future cleanup, rename this variable.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
>
>> @@ -438,7 +437,7 @@ static struct microcode_patch
>> *cpu_request_m
On 3/30/20 12:59, Ding Xiang wrote:
Fix a static code checker warning:
drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
warn: passing zero to 'PTR_ERR'
Signed-off-by: Ding Xiang
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
On 31.03.2020 12:05, Andrew Cooper wrote:
> @@ -497,57 +456,54 @@ static struct microcode_patch
> *cpu_request_microcode(const void *buf, size_t siz
> * It's possible the data file has multiple matching ucode,
> * lets keep searching till the latest version
> */
> -while ( (e
On 31.03.2020 12:05, Andrew Cooper wrote:
> With all the necessary cleanup now in place, fold struct microcode_header_amd
> into struct microcode_patch and drop the struct microcode_amd temporary
> ifdef-ary.
>
> This removes the memory allocation of struct microcode_amd which is a single
> pointe
On 31/03/2020 15:51, Jan Beulich wrote:
> On 31.03.2020 12:05, Andrew Cooper wrote:
>> @@ -497,57 +456,54 @@ static struct microcode_patch
>> *cpu_request_microcode(const void *buf, size_t siz
>> * It's possible the data file has multiple matching ucode,
>> * lets keep searching till t
On 31.03.2020 12:05, Andrew Cooper wrote:
> @@ -269,55 +265,25 @@ static int apply_microcode(const struct microcode_patch
> *patch)
> return 0;
> }
>
> -static int scan_equiv_cpu_table(
> -const void *data,
> -size_t size_left,
> -size_t *offset)
> +static int scan_equiv_cpu_ta
On 31.03.2020 16:55, Andrew Cooper wrote:
> On 31/03/2020 15:51, Jan Beulich wrote:
>> On 31.03.2020 12:05, Andrew Cooper wrote:
>>> @@ -497,57 +456,54 @@ static struct microcode_patch
>>> *cpu_request_microcode(const void *buf, size_t siz
>>> * It's possible the data file has multiple match
On Tue, Mar 31, 2020 at 05:50:10PM +0300, Oleksandr Andrushchenko wrote:
> On 3/30/20 12:59, Ding Xiang wrote:
> > Fix a static code checker warning:
> > drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
> > warn: passing zero to 'PTR_ERR'
> >
> > Signed-off-by: Ding Xian
On 31/03/2020 16:07, Jan Beulich wrote:
> On 31.03.2020 12:05, Andrew Cooper wrote:
>> @@ -269,55 +265,25 @@ static int apply_microcode(const struct
>> microcode_patch *patch)
>> return 0;
>> }
>>
>> -static int scan_equiv_cpu_table(
>> -const void *data,
>> -size_t size_left,
>> -
On 31.03.2020 17:19, Andrew Cooper wrote:
> On 31/03/2020 16:07, Jan Beulich wrote:
>> On 31.03.2020 12:05, Andrew Cooper wrote:
>>> @@ -269,55 +265,25 @@ static int apply_microcode(const struct
>>> microcode_patch *patch)
>>> return 0;
>>> }
>>>
>>> -static int scan_equiv_cpu_table(
>>> -
flight 149211 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149211/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail in 149173
pass in 149211
test-amd64-i386-qemuu
On 20.03.2020 19:42, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest linear TLB flush,
> which is an ASID/VPID tickle that forces a guest linear to guest
> physical TLB flush for all HVM guests.
>
> This was previously unconditionally done in each pre_flush call, but
> th
flight 149234 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 31/03/2020 16:13, Jan Beulich wrote:
> On 31.03.2020 16:55, Andrew Cooper wrote:
>> On 31/03/2020 15:51, Jan Beulich wrote:
>>> On 31.03.2020 12:05, Andrew Cooper wrote:
@@ -497,57 +456,54 @@ static struct microcode_patch
*cpu_request_microcode(const void *buf, size_t siz
*
On 31.03.2020 17:47, Andrew Cooper wrote:
> On 31/03/2020 16:13, Jan Beulich wrote:
>> On 31.03.2020 16:55, Andrew Cooper wrote:
>>> On 31/03/2020 15:51, Jan Beulich wrote:
On 31.03.2020 12:05, Andrew Cooper wrote:
> @@ -497,57 +456,54 @@ static struct microcode_patch
> *cpu_request_m
On 31/03/2020 16:27, Jan Beulich wrote:
> On 31.03.2020 17:19, Andrew Cooper wrote:
>> On 31/03/2020 16:07, Jan Beulich wrote:
>>> On 31.03.2020 12:05, Andrew Cooper wrote:
@@ -269,55 +265,25 @@ static int apply_microcode(const struct
microcode_patch *patch)
return 0;
}
>
Just the remaining two pieces of the original series.
1: vendor specific SYSCALL behavior
2: support SYSRET
Jan
AMD CPUs permit the insn everywhere (even outside of protected mode),
while Intel ones restrict it to 64-bit mode. While at it also comment
about the apparently missing CPUID bit check.
Signed-off-by: Jan Beulich
---
v2: Replace CPUID bit check by comment.
--- a/xen/arch/x86/x86_emulate/x86_emul
This is to augment SYSCALL, which we've been supporting for quite some
time.
Signed-off-by: Jan Beulich
---
v2: Replace CPUID bit check by comment. Limit RCX based canonical check
to just Intel as vendor. Update SS selector on AMD and alike.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b
On 31.03.2020 17:55, Andrew Cooper wrote:
> On 31/03/2020 16:27, Jan Beulich wrote:
>> On 31.03.2020 17:19, Andrew Cooper wrote:
>>> On 31/03/2020 16:07, Jan Beulich wrote:
On 31.03.2020 12:05, Andrew Cooper wrote:
> @@ -269,55 +265,25 @@ static int apply_microcode(const struct
> micr
On 31/03/2020 16:58, Jan Beulich wrote:
> AMD CPUs permit the insn everywhere (even outside of protected mode),
> while Intel ones restrict it to 64-bit mode. While at it also comment
> about the apparently missing CPUID bit check.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 31/03/2020 16:58, Jan Beulich wrote:
> This is to augment SYSCALL, which we've been supporting for quite some
> time.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
In some copious free time I'll see about finishing off my XTF test for
these cases, but that will have to wait for n
The orders of start and end are inverted in order to calculate the
size of the copy operation.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index
Obviously we want this!
Signed-off-by: Ian Jackson
---
Osstest.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index 54f0085c..1e381d8f 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -411,7 +411,7 @@ sub blessing_must_not_modify_host ($) {
# retur
This return value convention is convenient for the callers, since they
want to print a message when we mayn't modify.
Signed-off-by: Ian Jackson
---
Osstest.pm | 10 +-
Osstest/HostDB/Executive.pm | 4 ++--
ts-examine-hostprops-save | 4 ++--
3 files changed, 13 inse
On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote:
> On 20.03.2020 19:42, Roger Pau Monne wrote:
> > Introduce a specific flag to request a HVM guest linear TLB flush,
> > which is an ASID/VPID tickle that forces a guest linear to guest
> > physical TLB flush for all HVM guests.
> >
> >
> On Thu, 13 Feb 2020, Andrei Cherechesu wrote:
> > Hello,
> >
> > I used the Xen from Stefano's tree and made the updates to the partial
> > dtb that he specified.
> >
> > > This is mostly likely because Linux is trying to access a region
> > > that is not mapped in stage-2. You can rebuild Xen
Hi Jan,
On 31/03/2020 08:26, Jan Beulich wrote:
On 30.03.2020 21:21, Julien Grall wrote:
From: Julien Grall
At the moment, copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.
Thankfully, no users of the helper will do that. Rather than hoping this
can
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tre
On Tue, 31 Mar 2020, Andrei Cherechesu wrote:
> > On Thu, 13 Feb 2020, Andrei Cherechesu wrote:
> > > I used the Xen from Stefano's tree and made the updates to the partial
> > > dtb that he specified.
> > >
> > > > This is mostly likely because Linux is trying to access a region
> > > > that is
flight 149231 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 23 leak-check/checkfail REGR. vs. 149188
test-amd64-amd64-e
1 - 100 of 107 matches
Mail list logo
