flight 136999 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-i386-xsm
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, May 23, 2019 6:20 PM
>
> The various pieces of the hypercall page infrastructure have grown
> organically over time and ended up in a bit of a mess.
>
> * Rename all functions to be of the form *_init_hypercall_page(). T
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, May 14, 2019 8:04 PM
>
> The function passes 0 as "alloc" argument to addr_to_dma_page_maddr(),
> so -ENOMEM simply makes no sense (and its use was probably simply a
> copy-and-paste effect originating at intel_iommu_map_page()).
>
>
flight 136995 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136995/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c0fd7f734e2d33e22215899b40a47b843129541d
baseline version:
ovmf e812a812c1a0800c49e11
flight 136989 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
flight 136992 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136992/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 127792
build-i386-xsm
flight 136987 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136987/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 135251
test-amd64-amd64-xl-qemuu-win7-amd6
On Mon, May 27, 2019 at 9:55 AM George Dunlap wrote:
>
> On 4/12/19 9:08 PM, Tamas K Lengyel wrote:
> > The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view
> > when the guest traps out due to no EPT entry being present in the active
> > view.
> > Currently the function to
flight 136986 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134504
build-arm64
On 5/27/2019 9:18 AM, Roger Pau Monné wrote:
On Mon, Apr 29, 2019 at 05:27:34PM +0200, Roger Pau Monné wrote:
IMO it would be better if you can build directly from the upstream git
repository [0], that way you could use git-bisect(1) in order to figure
out which commit broke your system. For ex
flight 136981 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
test-amd64-i386-qem
flight 136970 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858
test-amd64-i386-exam
flight 136977 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136977/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136600
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 136975 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
> On May 27, 2019, at 2:47 AM, Peter Zijlstra wrote:
>
> On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote:
>> On 25/05/2019 10:22, Nadav Amit wrote:
>
>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>> b/arch/x86/include/asm/paravirt_types.h
>>> index 946f8f1f1efc..3a156e63
On Fri, May 24, 2019 at 04:01:23AM -0600, Jan Beulich wrote:
> >>> On 10.05.19 at 18:10, wrote:
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -855,20 +859,22 @@ static void _ns16550_resume(struct serial_port *port)
> > {
> > #ifdef CONFIG_HAS_PCI
> > struct ns1655
On 5/24/19 4:23 PM, Juergen Gross wrote:
> vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
> since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
> lists on domain creation"), but the callers test for -ENOSYS.
>
> Correct the callers.
>
> Signed-off-by: Juerge
On Mon, Apr 29, 2019 at 05:27:34PM +0200, Roger Pau Monné wrote:
> IMO it would be better if you can build directly from the upstream git
> repository [0], that way you could use git-bisect(1) in order to figure
> out which commit broke your system. For example:
>
> # git clone git://xenbits.xen.o
On Fri, May 24, 2019 at 10:29:26AM +0100, Andrew Cooper wrote:
> On 10/05/2019 17:10, Roger Pau Monne wrote:
> > This avoids code duplication between the helpers.
> >
> > No functional change intended.
> >
> > Signed-off-by: Roger Pau Monné
>
> -1. I see this as actively making the code worse, n
>>> On 27.05.19 at 17:48, wrote:
> On Fri, May 24, 2019 at 04:36:42AM -0600, Jan Beulich wrote:
>> Since we can't
>> use entirely new format specifiers, did you consider (ab)using one
>> we rarely use, like %o, suffixed similarly like we do for %p? The
>> extension could be restricted to apply onl
On 4/12/19 9:08 PM, Tamas K Lengyel wrote:
> The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view
> when the guest traps out due to no EPT entry being present in the active view.
> Currently the function took several inputs that it didn't use and also
> locked/unlocked gfns
On Thu, May 23, 2019 at 09:29:44AM -0600, Jan Beulich wrote:
> >>> On 10.05.19 at 18:10, wrote:
> > --- a/xen/include/xen/pci.h
> > +++ b/xen/include/xen/pci.h
> > @@ -80,9 +80,8 @@ struct pci_dev {
> > struct arch_msix *msix;
> >
> > struct domain *domain;
> > -const u16 seg;
> >
On Fri, May 24, 2019 at 04:36:42AM -0600, Jan Beulich wrote:
> >>> On 10.05.19 at 18:10, wrote:
> > The new format specifier is '%pp', and prints a pci_sbdf_t using the
> > seg:bus:dev.func format. Replace all SBDFs printed using
> > '%04x:%02x:%02x.%u' to use the new format specifier.
>
> So on
>>> On 27.05.19 at 16:25, wrote:
> On Mon, May 27, 2019 at 07:15:27AM -0600, Jan Beulich wrote:
>> >>> On 27.05.19 at 14:39, wrote:
>> > On Thu, May 23, 2019 at 03:41:23AM -0600, Jan Beulich wrote:
>> >> >>> On 22.05.19 at 18:45, wrote:
>> >> > alternative_callN using inline assembly to generate
Let's clarify this a bit:
a very useful & clear reply -- if that's all in the docs/wiki already, I
managed to miss it!
thx!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, May 27, 2019 at 07:15:27AM -0600, Jan Beulich wrote:
> >>> On 27.05.19 at 14:39, wrote:
> > On Thu, May 23, 2019 at 03:41:23AM -0600, Jan Beulich wrote:
> >> >>> On 22.05.19 at 18:45, wrote:
> >> > alternative_callN using inline assembly to generate the alternative
> >> > patch sites shou
>>> On 27.05.19 at 14:39, wrote:
> On Thu, May 23, 2019 at 03:41:23AM -0600, Jan Beulich wrote:
>> >>> On 22.05.19 at 18:45, wrote:
>> > alternative_callN using inline assembly to generate the alternative
>> > patch sites should be using the ALTERNATIVE C preprocessor macro
>> > rather than the A
flight 137007 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137007/
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 27/05/19 14:32, Peter Zijlstra wrote:
> On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote:
>> On 27/05/19 11:47, Peter Zijlstra wrote:
>
>>> --- a/arch/x86/kernel/kvm.c
>>> +++ b/arch/x86/kernel/kvm.c
>>> @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi
>>>
>>> static
On Thu, May 23, 2019 at 03:41:23AM -0600, Jan Beulich wrote:
> >>> On 22.05.19 at 18:45, wrote:
> > alternative_callN using inline assembly to generate the alternative
> > patch sites should be using the ALTERNATIVE C preprocessor macro
> > rather than the ALTERNATIVE assembly macro,
>
> Why? See
On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote:
> On 27/05/19 11:47, Peter Zijlstra wrote:
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi
> >
> > static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask);
commit 72813bfbf0276a97c82af038efb5f02dcdd9e310 upstream
This involves initializing the boot params EFI related fields and the
efi global variable.
Without this fix a PVH dom0 doesn't detect when booted from EFI, and
thus doesn't support accessing any of the EFI related data.
Reported-by: PGNet
On Fri, May 10, 2019 at 01:48:58AM -0600, Jan Beulich wrote:
> >>> On 10.05.19 at 03:28, wrote:
> > Hi all,
> >
> > following a discussion with committers about Guest testing in OSSTEST, it
> > surfaced that we have not updated what distros we test in OSSTEST for a
> > very
> > long time. All
On Fri, May 24, 2019 at 08:33:51AM -0700, PGNet Dev wrote:
> After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0
> successfully boots in PVH mode (dom0=pvh ...), with efi vars available so
> that efibootmgr functions,
>
> xl list
> Name
>>> On 27.05.19 at 12:51, wrote:
> On 4/2/19 2:01 PM, Jan Beulich wrote:
>> This is to accompany sanitize_input(). Just like for initial state we
>> want to have state between two emulated insns sane, at least as far as
>> assumptions in the main emulator go. Do minimal checking after segment
>> r
On 4/2/19 2:01 PM, Jan Beulich wrote:
> This is to accompany sanitize_input(). Just like for initial state we
> want to have state between two emulated insns sane, at least as far as
> assumptions in the main emulator go. Do minimal checking after segment
> register, CR, and MSR writes, and roll ba
Tmem has been an experimental Xen feature which has been dropped
recently due to security problems and lack of maintainership.
So it is time now to drop it in Linux kernel, too.
Juergen Gross (3):
xen: remove tmem driver
mm: remove cleancache.c
mm: remove tmem specifics from frontswap
Doc
The Xen tmem (transcendent memory) driver can be removed, as the
related Xen hypervisor feature never made it past the "experimental"
state and will be removed in future Xen versions (>= 4.13).
The xen-selfballoon driver depends on tmem, so it can be removed, too.
Signed-off-by: Juergen Gross
--
On 4/1/19 8:42 AM, Jan Beulich wrote:
> Don't enforce any other dependencies for now, just like we don't enforce
> e.g. PAE enabled as a prereq for long mode.
>
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@
On 27/05/19 11:47, Peter Zijlstra wrote:
> On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote:
>> On 25/05/2019 10:22, Nadav Amit wrote:
>
>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>> b/arch/x86/include/asm/paravirt_types.h
>>> index 946f8f1f1efc..3a156e63c57d 100644
>>>
On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote:
> On 25/05/2019 10:22, Nadav Amit wrote:
> > diff --git a/arch/x86/include/asm/paravirt_types.h
> > b/arch/x86/include/asm/paravirt_types.h
> > index 946f8f1f1efc..3a156e63c57d 100644
> > --- a/arch/x86/include/asm/paravirt_types.h
>
>>> On 24.05.19 at 19:44, wrote:
> Following the recent discussion, we had on IRC and the action I had in
> the March community call, this file provides a file format that
> enables writing an automated test to check whether files are out of sync.
>
> An example, what file content may look lik
>>> On 12.04.19 at 13:41, wrote:
On 11.04.19 at 21:06, wrote:
> > On 11/04/2019 13:45, Jan Beulich wrote:
> >> When disabling SMT at runtime, secondary threads should no longer be
> >> candidates for bringing back up in response to _PUD ACPI events. Purge
> >> them from the tracking array.
>
>>> On 05.04.19 at 16:27, wrote:
> Just like for other family values of 0x17 (see "x86/AMD: correct certain
> Fam17 checks"), commit 3157bb4e13 ("Add MSR support for various feature
> AMD processor families") made the original check for Fam11 here include
> families all the way up to Fam17. The in
>>> On 25.03.19 at 09:41, wrote:
On 22.03.19 at 20:56, wrote:
> > On 19/03/2019 09:16, Jan Beulich wrote:
> >> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
> >> families") converted certain checks for Fam11 to include families all
> >> the way up to Fam17. The commit
From: Andrii Anisov
This reduces the number of context switches in case we have coming guest
interrupts from different sources at a high rate. What is likely for
multimedia use-cases.
Having irqs unlocked here makes us go through trap path again in case we
have a new guest interrupt arrived (even
>>> On 02.04.19 at 15:04, wrote:
> In x2APIC mode it is 32 bits wide.
>
> In __print_IO_APIC() drop logging of both physical and logical IDs:
> The latter covers a superset of the bits of the former in the RTE, and
> we write full 8-bit values anyway even in physical mode for all ordinary
> inter
>>> On 02.04.19 at 15:01, wrote:
> This is to accompany sanitize_input(). Just like for initial state we
> want to have state between two emulated insns sane, at least as far as
> assumptions in the main emulator go. Do minimal checking after segment
> register, CR, and MSR writes, and roll back t
>>> On 01.04.19 at 09:42, wrote:
> Don't enforce any other dependencies for now, just like we don't enforce
> e.g. PAE enabled as a prereq for long mode.
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emu
>>> On 13.03.19 at 13:39, wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into toggle_guest_mode().
>
>>> On 31.01.19 at 15:07, wrote:
> This goes alongside Norbert's series, dealing with a few more
> places where I happened to know (without any analysis tools)
> guest controlled array accesses sit. I've additionally also
> checked emul-i8254.c, and I think no adjustments are needed
> there (there
flight 136969 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136969/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 136894
test-amd64-i386-xl-qemuu-win7-amd64
On Mon, May 20, 2019 at 4:48 PM Mauro Carvalho Chehab
wrote:
>
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
For the ACPI part:
Acked-by: Rafael J. Wysocki
_
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-vhd
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux
gi
This patch provides a tool for late microcode update.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Chao Gao
---
Changes in v7:
- introduce xc_microcode_update() rather than xc_platform_op()
- avoid creating bounce buffer twice
- rename xenmicrocode to xen-ucode, following naming tradit
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all cores
Changes in version 7:
- cache one microcode update rather than a list of it. Assuming that all CPUs
(including those will be plugged in later) in the system have the same
signature, one update matches with one CPU should match with others. Thus, one
update is enough for microcode updating durin
We can remove the per-cpu cache field in struct ucode_cpu_info since
it has been replaced by a global cache. It would leads to only one field
remaining in ucode_cpu_info. Then, this struct is removed and the
remaining field (cpu signature) is stored in per-cpu area.
Also remove 'microcode_resume_m
Updating microcode is less error prone when caches have been flushed and
depending on what exactly the microcode is updating. For example, some
of the issues around certain Broadwell parts can be addressed by doing a
full cache flush.
With parallel microcode update, the cost of this patch is hardl
to a more generic function. Then, this function can compare two given
microcodes' signature/revision as well. Comparing two microcodes is
used to update the global microcode cache (introduced by the later
patches in this series) when a new microcode is given.
Note that enum microcode_match_result
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
---
xen/arch/x86/a
to replace the current per-cpu cache 'uci->mc'.
With the assumption that all CPUs in the system have the same signature
(family, model, stepping and 'pf'), one microcode update matches with
one cpu should match with others. And Having multiple microcode revisions
on different cpus would cause syst
From: Sergey Dyasli
Currently cpu_sig struct is not updated during boot when either:
1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
2. initrd does not contain a microcode blob
These will result in cpu_sig.rev being 0 which affects APIC's
check_deadline_errata() and retp
During late microcode update, apply_microcode() is invoked in
cpu_request_microcode(). To make late microcode update more reliable,
we want to put the apply_microcode() into stop_machine context. So
we split out it from cpu_request_microcode(). As a consequence,
apply_microcode() should be invoked
microcode_update_lock is to prevent logic threads of a same core from
updating microcode at the same time. But due to using a global lock, it
also prevented parallel microcode updating on different cores.
Remove this lock in order to update microcode in parallel. It is safe
because we have already
>>> On 24.05.19 at 22:48, wrote:
> On 24/05/2019 07:43, Jan Beulich wrote:
> On 23.05.19 at 18:15, wrote:
>>> On 15/03/2019 10:55, Jan Beulich wrote:
Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
Note that despite the replacement of the SHA insns' table slots the
66 matches
Mail list logo
