flight 114177 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
Tests which
On Tue, Oct 03, 2017 at 11:08:01AM +0100, Roger Pau Monné wrote:
>On Tue, Oct 03, 2017 at 09:55:44AM +, osstest service owner wrote:
>> flight 113959 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/113959/
>>
>> Regressions :-(
>>
>> Tests which did not succeed an
>>> On 06.10.17 at 19:06, wrote:
> On 10/06/2017 04:54 PM, Jan Beulich wrote:
> On 06.10.17 at 17:21, wrote:
>>> On Mon, Sep 25, 2017 at 3:26 PM, George Dunlap
>>> wrote:
> One more thing:
>
>> @@ -1249,10 +1249,10 @@ static void __put_rep_prefix(
>>
>> /* Clip maximum repetitions so that
>>> On 06.10.17 at 18:07, wrote:
> On 10/06/2017 06:34 PM, Jan Beulich wrote:
> On 05.10.17 at 17:42, wrote:
>>> @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
>>> case HVMOP_altp2m_destroy_p2m:
>>> case HVMOP_altp2m_switch_p2m:
>>> case HVMOP_altp2m_set_mem_access:
>>> +ca
On 09.10.2017 10:23, Jan Beulich wrote:
On 06.10.17 at 18:07, wrote:
On 10/06/2017 06:34 PM, Jan Beulich wrote:
On 05.10.17 at 17:42, wrote:
@@ -4451,6 +4453,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_destroy_p2m:
case HVMOP_altp2m_switch_p2m:
case HVMOP_altp2m_set_mem
This run is configured for baseline tests only.
flight 72217 xen-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72217/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 7 xen-b
Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
leading to ugly recovered #GP fault messages with debug builds on older
systems. We can do better, so introduce synthetic feature flags for
both this and PLATFORM_INFO to avoid the rdmsr_safe() altogether.
Note that the r/o natu
Therefore all write attempts should produce #GP, just like on real
hardware.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v2: Group case label with other r/o MSRs.
---
Assumed to be applied on top of the (trivial) backport of 46c3acb308
("x86/vvmx: Fix WRMSR interception of VMX M
>>> On 06.10.17 at 18:53, wrote:
> On Sat, Sep 30, 2017 at 01:39:12AM +, Yi Sun wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -37,6 +37,16 @@
>> #include
>> #include
>>
>> +#define domctl_psr_get_val(d, domctl, type, copyback) ({ \
>> +int r__;
>>> On 08.10.17 at 07:29, wrote:
> Whatever the fix would be applied to guest kernel side, I think the root cause
> is because xen hypervisor returns a RUNSTATE_runnable time less than the
> previous one before live migration.
>
> As I am not clear enough with xen scheduling, I do not understand
>>> On 09.10.17 at 08:00, wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -122,8 +122,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index,
> int *pirq_p,
> break;
>
> case MAP_PIRQ_TYPE_MSI:
> -if ( !msi->table_base )
> -msi-
>>> On 06.10.17 at 19:41, wrote:
> @@ -40,7 +38,8 @@ struct xencons_interface {
> XENCONS_RING_IDX out_cons, out_prod;
> };
>
> -#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +#if defined(XEN_WANT_FLEX_CONSOLE_RING)
With this becoming #ifdef
Reviewed-by: Jan Beulich
Jan
___
On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:
The ARM 32&64 ELF specification says "sections containing ARM
code must be at least 32-bit aligned." This patch adds the
check for that. We also make sure that this check is done
when doing relocations for the types that are considered
ARM code
flight 114134 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 12 guest-start fail REGR. vs. 114036
test-amd64-amd64-xl-p
On Mon, Oct 09, 2017 at 02:13:22PM +0800, Chao Gao wrote:
>On Tue, Oct 03, 2017 at 11:08:01AM +0100, Roger Pau Monné wrote:
>>On Tue, Oct 03, 2017 at 09:55:44AM +, osstest service owner wrote:
>>> flight 113959 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/113959
Looks good for me.
Reviewed-by: Joe Jin
On 10/09/2017 02:00 PM, Zhenzhong Duan wrote:
> Same code is already in allocate_and_map_msi_pirq()
>
> Signed-off-by: Zhenzhong Duan
> ---
> xen/arch/x86/physdev.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch
flight 72218 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72218/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a
build-arm64-pvops
On 10/05/2017 03:50 PM, Volodymyr Babchuk wrote:
> Hi Konrad,
>
> On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote:
>> On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote:
>>> Added type xen_uuid_t. This type represents UUID as an array of 16
>>> bytes in big endian format.
>>>
>>> Add
>>> On 28.09.17 at 19:06, wrote:
> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -332,6 +332,23 @@ void stop_timer(struct timer *timer)
> }
>
>
> +bool timer_expires_before(struct timer *timer, s_time_t t)
> +{
> +unsigned long flags;
> +bool ret = false;
> +
> +if ( !t
On 09/10/17 08:48, Jan Beulich wrote:
> Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
> leading to ugly recovered #GP fault messages with debug builds on older
> systems. We can do better, so introduce synthetic feature flags for
> both this and PLATFORM_INFO to avoid the rd
On 09/10/17 08:49, Jan Beulich wrote:
> Therefore all write attempts should produce #GP, just like on real
> hardware.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@list
The backing structure for XEN_DOMCTL_getvcpucontext is only zeroed in the x86
HVM case. At the very least, this means that ARM returns junk through its
flags field (as it is only ever conditionally or'd into), and x86 PV leaks
data through gdt_frames[14...15]. (An exhaustive search for other leak
>>> On 09.10.17 at 11:49, wrote:
> On 09/10/17 08:48, Jan Beulich wrote:
>> Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
>> leading to ugly recovered #GP fault messages with debug builds on older
>> systems. We can do better, so introduce synthetic feature flags for
>> bot
On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 05.10.17 at 17:42, wrote:
> > @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
> > case HVMOP_altp2m_destroy_p2m:
> > case HVMOP_altp2m_switch_p2m:
> > case HVMOP_altp2m_set_mem_access:
> > +case
>>> On 28.09.17 at 19:06, wrote:
> Make it possible for the user to specify, with the boot
> time parameter rcu-idle-timer-period-ms, how frequently
> a CPU that went idle with pending RCU callbacks should be
> woken up to check if the grace period ended.
>
> Typical values (i.e., some of the val
flight 114182 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
Tests which
>>> On 09.10.17 at 12:10, wrote:
> On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
>> > > > On 05.10.17 at 17:42, wrote:
>> > +switch ( a.cmd )
>> > +{
>> > +case HVMOP_altp2m_set_mem_access_multi:
>> > +#define XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list(_d_,
>> > _s_
From: Andrew Cooper
An access which crosses a page boundary is performed atomically by x86
hardware, albeit with a severe performance penalty. An important corner case
is when a straddled access hits two pages which differ in whether a
translation exists, or in net access rights.
The use of hvm
Hi Andrew,
On 05/10/17 19:23, Andrew Cooper wrote:
A git tree version is available:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dombuilder-gnt-v1
I have tested it on Arm64 and didn't spot any regression so far:
Tested-by: Julien Grall
Cheers,
--
Juli
On 09/10/17 08:58, Chao Gao wrote:
> On Mon, Oct 09, 2017 at 02:13:22PM +0800, Chao Gao wrote:
>> On Tue, Oct 03, 2017 at 11:08:01AM +0100, Roger Pau Monné wrote:
>>> On Tue, Oct 03, 2017 at 09:55:44AM +, osstest service owner wrote:
flight 113959 xen-unstable real [real]
http://logs.
On 09/04/2017 09:47 AM, Jan Beulich wrote:
On 01.09.17 at 18:28, wrote:
>> On 01/09/17 17:18, Jan Beulich wrote:
>>> There is no need to hold the global domctl lock while across
>>> domain_kill() - the domain lock is fully sufficient here.
>>>
>>> Signed-off-by: Jan Beulich
>>> ---
>>> Sadly
flight 114142 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 113448
build-amd64-lib
On Lu, 2017-10-09 at 04:36 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 09.10.17 at 12:10, wrote:
> > On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 05.10.17 at 17:42, wrote:
> > > > +switch ( a.cmd )
> > > > +{
> >
One reason we want this is that it contains a reasonably easy-to-parse
record of the host memory.
When we have collected this information for all hosts, as xl info
output, we can write a program to copy the information into a host
property. This will allow us to restrict certain jobs to hosts wit
Hi Andrew,
On 09/10/17 11:07, Andrew Cooper wrote:
The backing structure for XEN_DOMCTL_getvcpucontext is only zeroed in the x86
HVM case. At the very least, this means that ARM returns junk through its
flags field (as it is only ever conditionally or'd into), and x86 PV leaks
data through gdt_
>>> On 05.10.17 at 19:42, wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -50,8 +50,6 @@ struct map_range_data
> /* Override macros from asm/page.h to make them work with mfn_t */
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> -#unde
>>> On 09.10.17 at 13:19, wrote:
> On Lu, 2017-10-09 at 04:36 -0600, Jan Beulich wrote:
>> > > > On 09.10.17 at 12:10, wrote:
>> > On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
>> > > > > > On 05.10.17 at 17:42, wrote:
>> > > > --- a/xen/tools/compat-build-header.py
>> > > > +++ b/xen/too
>>> On 09.10.17 at 13:08, wrote:
> On 09/04/2017 09:47 AM, Jan Beulich wrote:
> On 01.09.17 at 18:28, wrote:
>>> On 01/09/17 17:18, Jan Beulich wrote:
There is no need to hold the global domctl lock while across
domain_kill() - the domain lock is fully sufficient here.
Sig
On Mon, Oct 09, 2017 at 12:03:53PM +0100, Andrew Cooper wrote:
>On 09/10/17 08:58, Chao Gao wrote:
>> On Mon, Oct 09, 2017 at 02:13:22PM +0800, Chao Gao wrote:
>>> On Tue, Oct 03, 2017 at 11:08:01AM +0100, Roger Pau Monné wrote:
On Tue, Oct 03, 2017 at 09:55:44AM +, osstest service owner w
Hi Jan,
On 09/10/17 12:42, Jan Beulich wrote:
On 05.10.17 at 19:42, wrote:
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -50,8 +50,6 @@ struct map_range_data
/* Override macros from asm/page.h to make them work with mfn_t */
#undef virt_to_mfn
#define virt_to_mfn
Hi,
On 02/10/17 18:31, Julien Grall wrote:
Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.
Introduce a couple of new flags for the permissions (Non-eXecutable,
Read-Only) and a
flight 114188 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
Tests which
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -33,6 +33,44 @@
>
> #include
>
> +static void set_ioreq_server(struct domain *d, unsigned int id,
> + struct hvm_ioreq_server *s)
> +{
> +ASSERT(id < MAX_NR
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 October 2017 13:40
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v9 01/11] x86/hvm/ioreq: maintain an array of ioreq
> servers rather than a list
>
> >>> On 06
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -357,6 +357,9 @@ static void hvm_update_ioreq_evtchn(struct
> hvm_ioreq_server *s,
> }
> }
>
> +#define HANDLE_BUFIOREQ(s) \
> +(s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 October 2017 13:46
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ;
> Stefano Stabellini ; xen-de...@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH
On 25/09/17 15:26, George Dunlap wrote:
> From: Jan Beulich
>
> fuzz_insn_fetch() is the only data access helper where it is possible
> to see offsets larger than 4Gb in 16- or 32-bit modes, as we leave the
> incoming rIP untouched in the emulator itself.
Is it reasonable to tolerate this? AFAIC
flight 114148 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 12 guest-start fail REGR. vs. 114042
test-amd64-amd64-
>>> On 06.10.17 at 14:25, wrote:
> @@ -395,6 +397,39 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
> }
> #endif
>
> +case XENMEM_acquire_resource:
> +{
> +xen_ulong_t *gmfn_list = (xen_ulong_t *)(nat.mar + 1);
> +
> +
Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.
Introduce a couple of new flags for the permissions (Non-eXecutable,
Read-Only) and also provides definition that combine the memor
Currently, all the new mappings will be read-write non-executable. Allow the
caller to use other permissions.
Signed-off-by: Julien Grall
---
Changes in v2:
- Switch the runtime check to a BUG_ON()
---
xen/arch/arm/mm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch
The description of AP[1] in Xen is based on testing rather than the ARM
ARM.
Per the ARM ARM, on EL2 stage-1 page table, AP[1] is RES1 as the
translation regime applies to only one exception level (see D4.4.4 and
G4.6.1 in ARM DDI 0487B.a).
Update the comment and also rename the field to match th
The parameter 'ai' is used either for attribute index or for
permissions. Follow-up patch will rework that parameters to carry more
information. So rename the parameter to 'flags'.
Signed-off-by: Julien Grall
Reviewed-by: Andre Przywara
Reviewed-by: Stefano Stabellini
---
Changes in v3:
At the moment, PAGE_HYPERVISOR_* and MT_* have exactly the same value.
In a follow-up patch the former will be extended to carry more
information.
It looks like the caller of set_fixmap are mixing the both. Stay
consistent and only use PAGE_HYPERVISOR_*. This is also match the
behavior of create_x
Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
both hardcoded value. This makes quite difficult to understand the value
written in both registers.
Rework the definition by using value of each attribute shifted by their
associated index.
Signed-off-by: Julien Grall
Review
This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). Each
type will contain "NORMAL" or "DEVICE" to make clear whether each attribute
targets device or normal memory.
Signed-off-by: Julien Grall
---
Changes in v3:
- The ai '000' is named MT_DEVICE_nGnRnE and no
This will help to consolidate the page-table code and avoid different
path depending on the action to perform.
Signed-off-by: Julien Grall
Reviewed-by: Andre Przywara
Reviewed-by: Stefano Stabellini
Reviewed-by: Konrad Rzeszutek Wilk
---
Cc: Konrad Rzeszutek Wilk
Cc: Ross Lagerwall
ar
Hi all,
This patch series contains clean-up for the ARM memory subsystem in preparation
of reworking the page tables handling.
For all changes, see in each patch.
Cheers,
Julien Grall (10):
xen/arm: page: Use ARMv8 naming to improve readability
xen/arm: page: Clean-up the definition of MAIR
Currently, the flags used to update page tables (i.e PAGE_HYPERVISOR_*)
only contains the memory attribute index. Follow-up patches will add
more information in it. So document the current layout.
At the same time introduce PAGE_AI_MASK to get the memory attribute
index easily.
Signed-off-by: Jul
We should consider the early boot period to end when we stop using the
boot allocator. This is inline with x86 and will be helpful to know
whether we should allocate memory from the boot allocator or xenheap.
Signed-off-by: Julien Grall
Reviewed-by: Andre Przywara
Reviewed-by: Stefano Stabellini
>>> On 09.10.17 at 14:54, wrote:
> On 25/09/17 15:26, George Dunlap wrote:
>> From: Jan Beulich
>>
>> fuzz_insn_fetch() is the only data access helper where it is possible
>> to see offsets larger than 4Gb in 16- or 32-bit modes, as we leave the
>> incoming rIP untouched in the emulator itself.
>
libxl_domain_build_info had both the maptrack and grant frames set to
0 by default, forcing the client of libxl to set a sane default.
This is not backwards compatible, so instead initialize both
max_grant_frames and max_maptrack_frames to a sane default (ie: like
previous behavior).
This fixes t
The recent grant-table commits have changed the behavior of xl/libxl,
and are currently causing regressions in the osstest tests.
The following two commits attempt to restore previous behavior by
setting a sane default number of grant/maptrack frames.
Note that only the first patch should be need
This is in line with the previous behavior, setting the number of
maptrack frames to 0 will prevent driver domains from working
correctly.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Juergen Gross
---
docs/man/xl.conf.pod.5 | 2 +-
tools/xl/xl.c | 2 +-
tools/x
Hi everyone.
this is a quick note that the proposal for the Unicore Proposal (see
http://markmail.org/message/ly3f6e53nv3jaxd7) has passed.
The calculation is as follows:
1) XAPI subproject: quorum not met; subproject’s vote discounted
2) Hypervisor subproject: quorum met
7 votes in favour (min
On 09/10/17 14:26, Jan Beulich wrote:
>
>>> (NB: put_rep_prefix() is what allows
>>> complete_insn to be reached with rc set to other than X86EMUL_OKAY or
>>> X86EMUL_DONE. See also commit 53f87c03b4 ["x86emul: generalize
>>> exception handling for rep_* hooks"].)
>>>
>>> Add assert()-s for all ot
>>> On 09.10.17 at 14:20, wrote:
> Hi Jan,
>
> On 09/10/17 12:42, Jan Beulich wrote:
> On 05.10.17 at 19:42, wrote:
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -50,8 +50,6 @@ struct map_range_data
>>> /* Override macros from asm/page.h to make them wo
Roger Pau Monne writes ("[PATCH 1/2] libxl: set the default grant/maptrack
frames at structure init"):
> libxl_domain_build_info had both the maptrack and grant frames set to
> 0 by default, forcing the client of libxl to set a sane default.
>
> This is not backwards compatible, so instead initia
Hi Jan,
On 09/10/17 14:40, Jan Beulich wrote:
On 09.10.17 at 14:20, wrote:
Hi Jan,
On 09/10/17 12:42, Jan Beulich wrote:
On 05.10.17 at 19:42, wrote:
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -50,8 +50,6 @@ struct map_range_data
/* Override macros from asm/p
> On 12 Sep 2017, at 16:35, Rich Persaud wrote:
>
>> On Sep 11, 2017, at 13:01, George Dunlap wrote:
>>
>> +### XSM & FLASK
>> +
>> +Status: Experimental
>> +
>> +Compile time disabled
>> +
>> +### XSM & FLASK support for IS_PRIV
>> +
>> +Status: Experimental
>
> In which specific are
On Sun, Oct 08, 2017 at 04:22:00AM +, Yi Sun wrote:
> It changes the memebers in 'cos_write_info' to transfer the feature array,
> feature properties array and value array. Then, we can write all features
> values on the cos id into MSRs.
>
> Because multiple features may co-exist, we need han
On Mon, Oct 09, 2017 at 11:34:02AM +, Ian Jackson wrote:
> One reason we want this is that it contains a reasonably easy-to-parse
> record of the host memory.
>
> When we have collected this information for all hosts, as xl info
> output, we can write a program to copy the information into a h
>>> On 09.10.17 at 15:48, wrote:
> On 09/10/17 14:40, Jan Beulich wrote:
> On 09.10.17 at 14:20, wrote:
>>> On 09/10/17 12:42, Jan Beulich wrote:
>>> On 05.10.17 at 19:42, wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -50,8 +50,6 @@ struc
From: Andrew Cooper
This hook appears to be missing from the Linux ubsan implemention. This patch
is a forward port of https://lkml.org/lkml/2014/10/20/182
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
xen/common/ubsan/ubsan.c | 19 +++
1 file c
From: Andrew Cooper
A future change will adjust it to compile in Xen.
Signed-off-by: Andrew Cooper
Signed-off-by: Wei Liu
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
xen/common/ubsan/Makefile | 1 +
xen/common/ubsan/ubsan.c | 456 ++
xen/com
Make the following changes:
1. Introduce CONFIG_UBSAN and other auxiliary options.
2. Introduce Build system rune to filter objects.
3. Make ubsan.c build.
Currently only x86 is supported. All init.o's are filtered out because
of limitation in the build system. There is no user of noubsan-y yet
b
Andrew Cooper (2):
xen/ubsan: Import ubsan implementation from Linux 4.13
xen/ubsan: Implement __ubsan_handle_nonnull_arg()
Wei Liu (1):
xen: hook up UBSAN with CONFIG_UBSAN
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Stefano Stabellini
Cc: Julien Grall
xen/Kconfig | 6 +
xe
> On 27 Sep 2017, at 13:57, Robert VanVossen
> wrote:
>
>
>
> On 9/26/2017 3:12 AM, Dario Faggioli wrote:
>> [Cc-list modified by removing someone and adding someone else]
>>
>> On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote:
>>> On Mon, 11 Sep 2017, George Dunlap wrote:
+#
flight 114172 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114172/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 728d74973c9262b6c7b7ef4be213223d55affec3
baseline version:
ovmf f8f0e454e1f9e0be354cf
I will try and run the XSA scripts this week and get back to you
Lars
On 06/10/2017, 14:33, "Jan Beulich" wrote:
All,
with the goal of releasing around the end of the month, please point
out backport candidates you find missing from the respective staging
branches, but which
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -965,6 +965,67 @@ static long xatp_permission_check(struct domain *d,
> unsigned int space)
> return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> }
>
> +#ifdef CONFIG_X86
> +static int a
On 09/10/17 15:11, Wei Liu wrote:
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 30c2769684..64955dc017 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
Based on Julien's testing, shouldn't ARM64 also select HAS_UBSAN?
Otherwise, LGTM.
~Andrew
___
On Mon, Oct 09, 2017 at 06:00:15AM +, Zhenzhong Duan wrote:
> Same code is already in allocate_and_map_msi_pirq()
>
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Roger Pau Monné
Whit one nit below.
> ---
> xen/arch/x86/physdev.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-
On Mon, Oct 09, 2017 at 03:23:37PM +0100, Andrew Cooper wrote:
> On 09/10/17 15:11, Wei Liu wrote:
> > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> > index 30c2769684..64955dc017 100644
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
>
> Based on Julien's testing, shoul
On 09/10/17 15:23, Andrew Cooper wrote:
On 09/10/17 15:11, Wei Liu wrote:
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 30c2769684..64955dc017 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
Based on Julien's testing, shouldn't ARM64 also select HAS_UBSAN?
I t
>>> On 09.10.17 at 16:11, wrote:
> --- a/xen/common/ubsan/ubsan.c
> +++ b/xen/common/ubsan/ubsan.c
> @@ -10,13 +10,18 @@
> *
> */
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> +#include
> +#include
> +
> +#define __noreturnnoreturn
> +#d
On 09/10/17 15:36, Jan Beulich wrote:
On 09.10.17 at 16:11, wrote:
>> --- a/xen/common/ubsan/ubsan.c
>> +++ b/xen/common/ubsan/ubsan.c
>> @@ -10,13 +10,18 @@
>> *
>> */
>>
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> +#include
>>
On Mon, Oct 09, 2017 at 03:38:55PM +0100, Andrew Cooper wrote:
> On 09/10/17 15:36, Jan Beulich wrote:
> On 09.10.17 at 16:11, wrote:
> >> --- a/xen/common/ubsan/ubsan.c
> >> +++ b/xen/common/ubsan/ubsan.c
> >> @@ -10,13 +10,18 @@
> >> *
> >> */
> >>
> >> -#include
> >> -#include
> >>
On Fri, Oct 06, 2017 at 08:00:00PM +0100, Andrew Cooper wrote:
> Mixed throughout libxc are uint32_t, int, and domid_t for domid parameters.
> With a signed type, and an explicitly 16-bit type, it is exceedingly difficult
> to construct an INVALID_DOMID constant which works with all of them. (The
On 09/10/17 15:47, Wei Liu wrote:
> On Fri, Oct 06, 2017 at 08:00:00PM +0100, Andrew Cooper wrote:
>> Mixed throughout libxc are uint32_t, int, and domid_t for domid parameters.
>> With a signed type, and an explicitly 16-bit type, it is exceedingly
>> difficult
>> to construct an INVALID_DOMID co
>>> On 09.10.17 at 16:38, wrote:
> On 09/10/17 15:36, Jan Beulich wrote:
> On 09.10.17 at 16:11, wrote:
>>> --- a/xen/common/ubsan/ubsan.c
>>> +++ b/xen/common/ubsan/ubsan.c
>>> @@ -10,13 +10,18 @@
>>> *
>>> */
>>>
>>> -#include
>>> -#include
>>> -#include
>>> -#include
>>> -#includ
Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new
-runasid option"):
> The last thing the QEMU command line needs is more exotic options. Are
> you sure we need a new one here? Can we make existing -runas serve?
> Precedence: Coreutils[*]. Pseudo-code:
>
> if ar
flight 114193 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114193/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
Tests which
(resending to right address for xen-devel)
Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new
-runasid option"):
> The last thing the QEMU command line needs is more exotic options. Are
> you sure we need a new one here? Can we make existing -runas serve?
> Precedence
On Mon, Oct 09, 2017 at 03:51:49PM +0100, Andrew Cooper wrote:
> On 09/10/17 15:47, Wei Liu wrote:
> > On Fri, Oct 06, 2017 at 08:00:00PM +0100, Andrew Cooper wrote:
> >> Mixed throughout libxc are uint32_t, int, and domid_t for domid parameters.
> >> With a signed type, and an explicitly 16-bit ty
>>> On 06.10.17 at 14:25, wrote:
> @@ -288,6 +301,61 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s,
> bool buf)
> return rc;
> }
>
> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct domain *currd = current->domain;
> +struct hvm_ior
On Mon, Oct 09, 2017 at 04:05:10PM +0100, Ian Jackson wrote:
> Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new
> -runasid option"):
> > The last thing the QEMU command line needs is more exotic options. Are
> > you sure we need a new one here? Can we make existing -
On Fri, Oct 06, 2017 at 07:04:49PM +0100, Andrew Cooper wrote:
> On 06/10/17 11:30, Roger Pau Monné wrote:
> > On Thu, Oct 05, 2017 at 06:23:44PM +, Andrew Cooper wrote:
> >> Recent changes in grant table configuration have caused calls to
> >> xc_dom_gnttab_init() to fail if not proceeded with
On 09/14/2017 04:12 PM, Jan Beulich wrote:
> I.e. those not being equivalents of SSEn ones.
>
> There's one necessary change to generic code: Faulting behavior of
> VMASKMOVP{S,D} requires us to do partial reads/writes.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Move vpmaskmov{d,q} handling to A
On 09/10/17 16:19, Wei Liu wrote:
> On Mon, Oct 09, 2017 at 03:51:49PM +0100, Andrew Cooper wrote:
>> On 09/10/17 15:47, Wei Liu wrote:
>>> On Fri, Oct 06, 2017 at 08:00:00PM +0100, Andrew Cooper wrote:
Mixed throughout libxc are uint32_t, int, and domid_t for domid parameters.
With a sig
1 - 100 of 197 matches
Mail list logo
