flight 125213 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
>>> On 13.07.18 at 22:03, wrote:
> More than the bottom two bits are now defined, and the MSR policy work has
> shown that using non-architectural representations turns out to be
> problematic
> for more than just asm code. As the architectural representation is the
> expected default, we don't
flight 125165 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
test-armhf-armhf-xl-multivcpu
>>> On 05.07.18 at 15:51, wrote:
> During early boot timestamps aren't very useful, as they're all zero
> (in "boot" mode) or absent altogether (in "date" and "datems" modes).
> Log "boot" format timestamps when the date formats aren't available yet,
> and log raw timestamps when boot ones are sti
flight 125216 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > > This is the v2 of RFC based on the feedback I've received so
>>> On 13.07.18 at 18:02, wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -168,6 +168,16 @@ $(TARGET).efi: ALT_BASE = 0x$(shell $(NM)
> efi/relocs-dummy.o | sed -n 's, A ALT_
> # Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
> $(TARGET).efi:
On 7/15/18 4:26 AM, Greg KH wrote:
> On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
>> Hi Greg,
>>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.14
On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beulich wrote:
> >>> On 13.07.18 at 18:02, wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -168,6 +168,16 @@ $(TARGET).efi: ALT_BASE = 0x$(shell $(NM)
> > efi/relocs-dummy.o | sed -n 's, A ALT_
> > # Don't use $(wildcard
On 07/02/2018 08:48 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Thursday, June 28, 2018 10:35 PM
>>
>> A VM exit handler executed immediately after enabling #VE might
>> find a stale __vmsave()d EPTP_INDEX, stored by calling
>> altp2m_vcpu_destroy() w
flight 125220 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125220/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
On 06/28/2018 07:19 PM, Tamas K Lengyel wrote:
> On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru
> wrote:
>>
>> For the hostp2m, access_required starts off as 0, then it can be
>> set with xc_domain_set_access_required(). However, all the altp2ms
>> set it to 1 on init, and ignore both the hostp2m
Use the calculated lengths instead of pointers, as 'e' being NULL will
otherwise cause undue parsing failures.
Reported-by: Karl Johnson
Signed-off-by: Jan Beulich
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -209,10 +209,11 @@ int parse_boolean(const char *name, cons
char bu
>>> On 16.07.18 at 10:30, wrote:
> On 07/02/2018 08:48 AM, Tian, Kevin wrote:
>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>>> Sent: Thursday, June 28, 2018 10:35 PM
>>>
>>> A VM exit handler executed immediately after enabling #VE might
>>> find a stale __vmsave()d EPTP_INDEX, sto
>>> On 16.07.18 at 10:35, wrote:
> On 06/28/2018 07:19 PM, Tamas K Lengyel wrote:
>> On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru
>> wrote:
>>>
>>> For the hostp2m, access_required starts off as 0, then it can be
>>> set with xc_domain_set_access_required(). However, all the altp2ms
>>> set it
>>> On 16.07.18 at 10:26, wrote:
> On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beulich wrote:
>> >>> On 13.07.18 at 18:02, wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -168,6 +168,16 @@ $(TARGET).efi: ALT_BASE = 0x$(shell $(NM)
>> > efi/relocs-dummy.o | sed
On Fri, Jul 13, 2018 at 09:03:06PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
> individual copies from the hypervisor and libxc respectively.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
On Mon, Jul 16, 2018 at 02:55:16AM -0600, Jan Beulich wrote:
> >>> On 16.07.18 at 10:26, wrote:
> > On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beulich wrote:
> >> >>> On 13.07.18 at 18:02, wrote:
> >> > --- a/xen/arch/x86/Makefile
> >> > +++ b/xen/arch/x86/Makefile
> >> > @@ -168,6 +168,16 @@
>>> On 13.07.18 at 11:02, wrote:
> On 11/07/18 14:04, Jan Beulich wrote:
>> While I've run into the issue with further patches in place which no
>> longer guarantee the per-CPU area to start out as all zeros, the
>> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
>> the per
On Fri, Jul 13, 2018 at 09:03:08PM +0100, Andrew Cooper wrote:
> +#include
> #include
> #include
> #include
> @@ -23,6 +28,19 @@ static inline bool test_bit(unsigned int bit, const void
> *vaddr)
> return addr[bit / 8] & (1u << (bit % 8));
> }
>
> +/* memcpy(), but with copy_to_gues
>>> On 16.07.18 at 11:12, wrote:
> On Mon, Jul 16, 2018 at 02:55:16AM -0600, Jan Beulich wrote:
>> >>> On 16.07.18 at 10:26, wrote:
>> > On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beulich wrote:
>> >> >>> On 13.07.18 at 18:02, wrote:
>> >> > --- a/xen/arch/x86/Makefile
>> >> > +++ b/xen/arch/
>>> On 13.07.18 at 22:03, wrote:
> Begin to untangle the header dependency tangle by moving definition of
> struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
>
> Additionally, plumb the header through to libxc. This is technically a
> redundant include at this point, but it helps buil
On Fri, Jul 13, 2018 at 09:03:09PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> As with CPUID, an architectural form is used for representing the MSR data.
> It is expected not to change moving forwards, but does have a 32 bit field
> (currently reserved) which can be used compatibly i
On Mon, Jul 16, 2018 at 03:18:13AM -0600, Jan Beulich wrote:
> >>> On 16.07.18 at 11:12, wrote:
> > On Mon, Jul 16, 2018 at 02:55:16AM -0600, Jan Beulich wrote:
> >> >>> On 16.07.18 at 10:26, wrote:
> >> > On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beulich wrote:
> >> >> >>> On 13.07.18 at 18:
>>> On 13.07.18 at 22:03, wrote:
> From: Roger Pau Monné
>
> This avoids all users needing to opencode local generation of the file.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing
On Fri, Jul 13, 2018 at 09:03:02PM +0100, Andrew Cooper wrote:
> More than the bottom two bits are now defined, and the MSR policy work has
> shown that using non-architectural representations turns out to be problematic
> for more than just asm code. As the architectural representation is the
> e
>>> On 13.07.18 at 22:03, wrote:
> --- a/tools/include/xen-tools/libs.h
> +++ b/tools/include/xen-tools/libs.h
> @@ -13,4 +13,8 @@
> #define ARRAY_SIZE(a) (sizeof(a) / sizeof(*a))
> #endif
>
> +#ifndef MAX
> +#define MAX(x, y) ((x) > (y) ? (x) : (y))
> +#endif
I find asymmetries like this odd
>>> On 13.07.18 at 20:54, wrote:
> Hello,
>
> I'm currently testing last Xen 4.8.4 build for CentOS
> (http://cbs.centos.org/koji/buildinfo?buildID=23169) and disabling
> XPTI for dom0 doesn't seem to work:
>
> (XEN) Command line: dom0_mem=1792M,max:2048M dom0_max_vcpus=4 cpuinfo
> com1=115200,8
On Fri, Jul 13, 2018 at 09:03:07PM +0100, Andrew Cooper wrote:
> To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
> needs to be available in the same way as struct cpuid_policy.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
__
>>> On 16.07.18 at 11:18, wrote:
> On Fri, Jul 13, 2018 at 09:03:08PM +0100, Andrew Cooper wrote:
>> +#include
>> #include
>> #include
>> #include
>> @@ -23,6 +28,19 @@ static inline bool test_bit(unsigned int bit, const void
> *vaddr)
>> return addr[bit / 8] & (1u << (bit % 8));
>>
On 16/07/18 10:38, Jan Beulich wrote:
On 13.07.18 at 22:03, wrote:
>> --- a/tools/include/xen-tools/libs.h
>> +++ b/tools/include/xen-tools/libs.h
>> @@ -13,4 +13,8 @@
>> #define ARRAY_SIZE(a) (sizeof(a) / sizeof(*a))
>> #endif
>>
>> +#ifndef MAX
>> +#define MAX(x, y) ((x) > (y) ? (x) : (
>>> On 16.07.18 at 11:25, wrote:
> On Mon, Jul 16, 2018 at 03:18:13AM -0600, Jan Beulich wrote:
>> >>> On 16.07.18 at 11:12, wrote:
>> > On Mon, Jul 16, 2018 at 02:55:16AM -0600, Jan Beulich wrote:
>> >> >>> On 16.07.18 at 10:26, wrote:
>> >> > On Mon, Jul 16, 2018 at 01:59:15AM -0600, Jan Beuli
On Fri, Jul 13, 2018 at 09:03:12PM +0100, Andrew Cooper wrote:
> This is prep work for the following patch - please refer to it as well.
>
> When auditing and manipulating policies, it is necessary to do so with a
> complete set of policies, due to the interdependences of the contents. A
> contai
On Fri, Jul 13, 2018 at 09:03:10PM +0100, Andrew Cooper wrote:
> As with the serialise side, Xen's copy_from_guest API is used, with a
> compatibility wrapper for the userspace build.
>
> Signed-off-by: Andrew Cooper
> Signed-off-by: Sergey Dyasli
> Signed-off-by: Roger Pau Monné
> ---
> CC: Ja
flight 125224 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 10:10
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ;
On 16/07/18 09:50, Jan Beulich wrote:
> Use the calculated lengths instead of pointers, as 'e' being NULL will
> otherwise cause undue parsing failures.
>
> Reported-by: Karl Johnson
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel
>>> On 16.07.18 at 11:51, wrote:
> On 16/07/18 10:38, Jan Beulich wrote:
> On 13.07.18 at 22:03, wrote:
>>> +static inline void cpuid_featureset_to_policy(
>>> +const uint32_t fs[FEATURESET_NR_ENTRIES], struct cpuid_policy *p)
>>> +{
>>> +p->basic._1d = fs[FEATURESET_1d];
>>> +p-
Hi Jan,
Sorry for the late answer.
On 16/07/18 08:33, Jan Beulich wrote:
On 05.07.18 at 15:51, wrote:
During early boot timestamps aren't very useful, as they're all zero
(in "boot" mode) or absent altogether (in "date" and "datems" modes).
Log "boot" format timestamps when the date formats a
On Fri, Jul 13, 2018 at 09:03:11PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Signed-off-by: Sergey Dyasli
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists
On 16/07/18 11:04, Jan Beulich wrote:
On 16.07.18 at 11:51, wrote:
>> On 16/07/18 10:38, Jan Beulich wrote:
>> On 13.07.18 at 22:03, wrote:
+static inline void cpuid_featureset_to_policy(
+const uint32_t fs[FEATURESET_NR_ENTRIES], struct cpuid_policy *p)
+{
+p
On Fri, Jul 13, 2018 at 09:03:13PM +0100, Andrew Cooper wrote:
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index dd7d8a9..ee3ab09 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2553,6 +2553,12 @@ int xc_get_cpu_levelling_c
>>> On 13.07.18 at 22:03, wrote:
> tools/libxc/Makefile | 6 ++
> tools/libxc/include/xenctrl.h | 1 -
> tools/libxc/xc_cpuid_x86.c | 29 +---
> xen/arch/x86/cpu/common.c | 2 +-
> xen/arch/x86/cpuid.c | 32 +
>>> On 13.07.18 at 22:03, wrote:
> To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
> needs to be available in the same way as struct cpuid_policy.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 11 July 2018 10:16
> To: Paul Durrant
> Cc: xen-devel ; Kevin Tian
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 07/13] iommu: track reserved ranges
> using a rangeset
>
On Mon, Jul 16, 2018 at 03:52:49AM -0600, Jan Beulich wrote:
> >>> On 16.07.18 at 11:25, wrote:
> > On Mon, Jul 16, 2018 at 03:18:13AM -0600, Jan Beulich wrote:
> >> >>> On 16.07.18 at 11:12, wrote:
> >> > On Mon, Jul 16, 2018 at 02:55:16AM -0600, Jan Beulich wrote:
> >> >> >>> On 16.07.18 at 10:
On 16/07/18 10:23, Jan Beulich wrote:
On 13.07.18 at 22:03, wrote:
>> Begin to untangle the header dependency tangle by moving definition of
>> struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
>>
>> Additionally, plumb the header through to libxc. This is technically a
>> redunda
>>> On 16.07.18 at 12:16, wrote:
> On 16/07/18 11:04, Jan Beulich wrote:
> On 16.07.18 at 11:51, wrote:
>>> On 16/07/18 10:38, Jan Beulich wrote:
>>> On 13.07.18 at 22:03, wrote:
> +static inline void cpuid_featureset_to_policy(
> +const uint32_t fs[FEATURESET_NR_ENTRIES], st
On Fri, Jul 13, 2018 at 09:03:14PM +0100, Andrew Cooper wrote:
> +int xc_get_domain_cpu_policy(xc_interface *xch, uint32_t domid,
> + uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
> + uint32_t *nr_msrs, xen_msr_entry_t *msrs)
> +{
> +DECL
On Fri, Jul 06, 2018 at 04:26:38PM +0200, Manuel Bouyer wrote:
> On Tue, Jul 03, 2018 at 06:17:28PM +0200, Manuel Bouyer wrote:
> > > So instead of the debugging patch, could you give the one below
> > > a try?
> >
> > Sure, the test server is now running with it.
> > As I'm still using 4.11rc4 so
On Fri, Jul 13, 2018 at 09:03:12PM +0100, Andrew Cooper wrote:
> This is prep work for the following patch - please refer to it as well.
>
> When auditing and manipulating policies, it is necessary to do so with a
> complete set of policies, due to the interdependences of the contents. A
> contai
On 16/07/18 11:17, Jan Beulich wrote:
On 13.07.18 at 22:03, wrote:
>> tools/libxc/Makefile | 6 ++
>> tools/libxc/include/xenctrl.h | 1 -
>> tools/libxc/xc_cpuid_x86.c | 29 +---
>> xen/arch/x86/cpu/common.c | 2 +-
>> xen/arch/x86/cpuid.c
On 16/07/18 10:45, Jan Beulich wrote:
On 16.07.18 at 11:18, wrote:
>> On Fri, Jul 13, 2018 at 09:03:08PM +0100, Andrew Cooper wrote:
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -23,6 +28,19 @@ static inline bool test_bit(unsigned int bit, const void
>> *vaddr)
>>>
>>> On 13.07.18 at 22:03, wrote:
> +int x86_cpuid_copy_to_buffer(const struct cpuid_policy *p,
> + cpuid_leaf_buffer_t leaves,
> + uint32_t *nr_entries_p)
> +{
> +const uint32_t nr_entries = *nr_entries_p;
> +uint32_t curr_entry = 0,
>>> On 13.07.18 at 22:03, wrote:
> From: Roger Pau Monné
>
> As with CPUID, an architectural form is used for representing the MSR data.
> It is expected not to change moving forwards, but does have a 32 bit field
> (currently reserved) which can be used compatibly if needs be.
>
> Signed-off-b
>>> On 16.07.18 at 12:22, wrote:
> On 16/07/18 10:23, Jan Beulich wrote:
> On 13.07.18 at 22:03, wrote:
>>> Begin to untangle the header dependency tangle by moving definition of
>>> struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
>>>
>>> Additionally, plumb the header through to
>>> On 16.07.18 at 12:35, wrote:
> On 16/07/18 11:17, Jan Beulich wrote:
> On 13.07.18 at 22:03, wrote:
>>> tools/libxc/Makefile | 6 ++
>>> tools/libxc/include/xenctrl.h | 1 -
>>> tools/libxc/xc_cpuid_x86.c | 29 +---
>>> xen/arch/x86/cpu/common
>>> On 16.07.18 at 12:39, wrote:
> On 16/07/18 10:45, Jan Beulich wrote:
> On 16.07.18 at 11:18, wrote:
>>> On Fri, Jul 13, 2018 at 09:03:08PM +0100, Andrew Cooper wrote:
+#include
#include
#include
#include
@@ -23,6 +28,19 @@ static inline bool test_bit(unsign
On 16/07/18 11:16, Roger Pau Monné wrote:
>
>> +
>> +sysctl.cmd = XEN_SYSCTL_get_cpu_policy;
>> +sysctl.u.cpu_policy.index = index;
>> +sysctl.u.cpu_policy.nr_leaves = *nr_leaves;
>> +set_xen_guest_handle(sysctl.u.cpu_policy.cpuid_policy, leaves);
>> +sysctl.u.cpu_policy.nr_msrs
>>> On 16.07.18 at 12:30, wrote:
> On Fri, Jul 06, 2018 at 04:26:38PM +0200, Manuel Bouyer wrote:
>> On Tue, Jul 03, 2018 at 06:17:28PM +0200, Manuel Bouyer wrote:
>> > > So instead of the debugging patch, could you give the one below
>> > > a try?
>> >
>> > Sure, the test server is now running w
On 16/07/18 10:37, Roger Pau Monné wrote:
> On Fri, Jul 13, 2018 at 09:03:02PM +0100, Andrew Cooper wrote:
>> More than the bottom two bits are now defined, and the MSR policy work has
>> shown that using non-architectural representations turns out to be
>> problematic
>> for more than just asm co
>>> On 16.07.18 at 12:58, wrote:
> On 16/07/18 11:16, Roger Pau Monné wrote:
>>
>>> +
>>> +sysctl.cmd = XEN_SYSCTL_get_cpu_policy;
>>> +sysctl.u.cpu_policy.index = index;
>>> +sysctl.u.cpu_policy.nr_leaves = *nr_leaves;
>>> +set_xen_guest_handle(sysctl.u.cpu_policy.cpuid_policy, le
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduce
>>> On 13.07.18 at 22:03, wrote:
> --- a/xen/common/libx86/msr.c
> +++ b/xen/common/libx86/msr.c
> @@ -45,6 +45,57 @@ int x86_msr_copy_to_buffer(const struct msr_policy *p,
> return 0;
> }
>
> +int x86_msr_copy_from_buffer(struct msr_policy *p,
> + const msr_ent
On 16/07/18 11:17, Jan Beulich wrote:
On 13.07.18 at 11:02, wrote:
>> On 11/07/18 14:04, Jan Beulich wrote:
>>> While I've run into the issue with further patches in place which no
>>> longer guarantee the per-CPU area to start out as all zeros, the
>>> CPU_DOWN_FAILED processing looks to hav
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.
Currently we simply back off and mark an oom
>>> On 13.07.18 at 22:03, wrote:
> @@ -322,6 +323,76 @@ long arch_do_sysctl(
> break;
> }
>
> +case XEN_SYSCTL_get_cpu_policy:
> +{
> +const struct cpu_policy *policy;
> +
> +/* Bad policy index? */
> +if ( sysctl->u.cpu_policy.index >= ARRAY_SIZE(sy
If panic is called before init_idle_domain on a tboot-launched system,
Xen recursively faults in write_ptbase as seen below.
(XEN)[] write_ptbase+0/0x10
(XEN)[] tboot_shutdown+0x6b/0x260
(XEN)[] machine_restart+0xac/0x2d0
(XEN)[] write_ptbase+0/0x10
(XEN)[] panic+0x111/0x120
(X
>>> On 13.07.18 at 22:03, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1523,6 +1523,40 @@ long arch_do_domctl(
> recalculate_cpuid_policy(d);
> break;
>
> +case XEN_DOMCTL_get_cpu_policy:
> +if ( !guest_handle_is_null(domctl->u.cpu_policy
>>> On 13.07.18 at 22:03, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -31,6 +31,33 @@
> #include
> #include
>
> +const struct cpu_policy system_policies[] = {
By the end of the series the array remains unused outside this
source file. I'd appreciate if it was mad
flight 125229 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
On 16/07/18 13:04, Jan Beulich wrote:
On 13.07.18 at 22:03, wrote:
>> --- a/xen/arch/x86/sysctl.c
>> +++ b/xen/arch/x86/sysctl.c
>> @@ -31,6 +31,33 @@
>> #include
>> #include
>>
>> +const struct cpu_policy system_policies[] = {
> By the end of the series the array remains unused outside
>>> On 16.07.18 at 13:47, wrote:
> On 16/07/18 11:17, Jan Beulich wrote:
> On 13.07.18 at 11:02, wrote:
>>> On 11/07/18 14:04, Jan Beulich wrote:
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
>>>
>>> On 16.07.18 at 13:59, wrote:
> --- a/xen/arch/x86/tboot.c
> +++ b/xen/arch/x86/tboot.c
> @@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
> tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, &xenheap_mac);
> }
>
> -write_ptbase(idle_vcpu[0]);
> +/* Duri
>>> On 16.07.18 at 14:16, wrote:
> On 16/07/18 13:04, Jan Beulich wrote:
> On 13.07.18 at 22:03, wrote:
>>> --- a/xen/arch/x86/sysctl.c
>>> +++ b/xen/arch/x86/sysctl.c
>>> @@ -31,6 +31,33 @@
>>> #include
>>> #include
>>>
>>> +const struct cpu_policy system_policies[] = {
>> By the end o
On 13/07/18 09:13, Jan Beulich wrote:
On 12.07.18 at 17:45, wrote:
>> On 11/07/18 13:10, Jan Beulich wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>>> ### hpetbroadcast (x
On 16/07/18 14:19, Jan Beulich wrote:
On 16.07.18 at 13:47, wrote:
>> On 16/07/18 11:17, Jan Beulich wrote:
>> On 13.07.18 at 11:02, wrote:
On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per
>>> On 07.07.18 at 01:14, wrote:
> Add a clear statement about them, reflecting the current security
> support status of Kconfig options (no changes to current policies).
>
> Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
___
Xen-devel ma
>>> On 16.07.18 at 14:37, wrote:
> On 13/07/18 09:13, Jan Beulich wrote:
> On 12.07.18 at 17:45, wrote:
>>> On 11/07/18 13:10, Jan Beulich wrote:
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1040,6 +1040,13 @@ identical to the boot CPU
>>> On 16.07.18 at 14:47, wrote:
> On 16/07/18 14:19, Jan Beulich wrote:
> On 16.07.18 at 13:47, wrote:
>>> On 16/07/18 11:17, Jan Beulich wrote:
>>> On 13.07.18 at 11:02, wrote:
> On 11/07/18 14:04, Jan Beulich wrote:
>> While I've run into the issue with further patches in plac
On 16/07/18 13:53, Jan Beulich wrote:
On 16.07.18 at 14:37, wrote:
>> On 13/07/18 09:13, Jan Beulich wrote:
>> On 12.07.18 at 17:45, wrote:
On 11/07/18 13:10, Jan Beulich wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@
On 16/07/18 13:29, Jan Beulich wrote:
On 16.07.18 at 14:16, wrote:
>> On 16/07/18 13:04, Jan Beulich wrote:
>> On 13.07.18 at 22:03, wrote:
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -31,6 +31,33 @@
#include
#include
+const struct
>>> On 16.07.18 at 15:15, wrote:
> On 16/07/18 13:29, Jan Beulich wrote:
> On 16.07.18 at 14:16, wrote:
>>> On 16/07/18 13:04, Jan Beulich wrote:
>>> On 13.07.18 at 22:03, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -31,6 +31,33 @@
> #include
This run is configured for baseline tests only.
flight 74974 qemu-upstream-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12 gu
On 06/06/18 14:37, Jan Beulich wrote:
> >>> On 04.06.18 at 15:59, wrote:
>> * State adjustments (and debug tracing) for #DB/#BP/#PF should not be done
>>for `int $n` instructions. Updates to %cr2 occur even if the exception
>>combines to #DF.
>> * Don't opencode DR_STEP when updating %d
flight 125226 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125226/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 04c77c18ada08a796cfe1d7545c0e76429e1d3dc
baseline version:
freebsd 414774b7931
Using plain int for instance numbers looks quite dangerous without
being aware that hvm_load_instance() returns an unsigned quantity. Make
this more explicit. Also replace uint16_t uses by unsigned int.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -976,
On 16/07/18 14:58, Jan Beulich wrote:
> Using plain int for instance numbers looks quite dangerous without
> being aware that hvm_load_instance() returns an unsigned quantity. Make
> this more explicit. Also replace uint16_t uses by unsigned int.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Co
Do not embed IPXE into Rombios anymore. Instead, it is loaded by the
toolstack from a file as a separate module.
Ability to let user specify an IPXE blob will come later.
No user visible change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
v3: adjust libxl code a bit, addressed Jan's comme
Update commit messages. No code change in this version.
Wei Liu (6):
Tools.mk.in: drop unused variables
ipxe: produce a single binary from its build
libxc: allow HVM guest to have modules
tools: load IPXE from standalone file
tools: provide --with-system-ipxe
tools: --with-system-{ovmf
And switch hvmloader/Makefile to use that binary. This will help later
when we change hvmloader to pick a user provided binary.
No functional change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
v2: use intermediary file
Cc: Ian Jackson
---
tools/firmware/etherboot/Makefile | 7 ++-
The paths shouldn't be set to "yes". We ask the user to set absolute
paths because Xen's build system doesn't know where to search, and the
build machine doesn't necessarily have those binaries present in the
first place.
Reported-by: Anthony Perard
Signed-off-by: Wei Liu
---
v3: really check fo
Lift the loading code out of PVH specific branch. Take the chance to
make the debug message more useful.
Now the code needs to handle virt_base being UNSET_ADDR, which it is
for HVM guest. In case virt_base is not set, it should be treated as
zero. In case PVH and PV, virt_base is set by the res
This option lets user specify which binary is to be used as ipxe. If
it is specified, the in-tree ipxe will not be built. This option is in
line with other --with-system-* options we provide.
Signed-off-by: Wei Liu
---
v3: ipxe should require rombios
Cc: Ian Jackson
---
config/Tools.mk.in
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
config/Tools.mk.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 2d6c440324..4cc9f29090 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -20,8 +20,6 @@ BCC := @BCC@
IAS
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 July 2018 14:58
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH] x86/HVM: improve a few state load checks
>
> Using plain int for instance numbers looks quite dangerous without
> being a
Hello,
The following patches started as a workaround to build Xen using lld
(the LLVM linker), but now patch #2 is an improvement of the build
system, thus allowing to create a multiboot2 capable ELF binary
requiring just a compiler that supports the MS ABI. Previously in order
to build a multiboo
So that an ELF binary with support for EFI services will be built when
the compiler supports the MS ABI, regardless of the linker support for
PE.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
Changes since v1:
- New in this version.
---
xen/arch/x8
So that it can be used by other components apart from the efi specific
code. By moving the detection code creating a dummy efi/disabled file
can be avoided.
This is required so that the conditional used to define the efi symbol
in the linker script can be removed and instead the definition of the
On 16/07/18 15:05, Paul Durrant wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -976,14 +976,13 @@ unsigned long hvm_cr4_guest_valid_bits(c
>>
>> static int hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
>> {
>> -int vcpuid;
>> +unsigned int vcpu
1 - 100 of 180 matches
Mail list logo
