This run is configured for baseline tests only.
flight 71978 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71978/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop
>>> On 15.08.17 at 19:14, wrote:
> On 15/08/17 15:41, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -158,7 +158,24 @@ shared_entry_header(struct grant_table *
>>
>> /* Active grant entry - used for shadowing GTF_permit_access grants. */
>> struct
Hi Julien,
On 11 August 2017 at 23:32, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/traps.c | 42 ++
> 1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c07999b
On 17-08-16 14:38:28, Chao Peng wrote:
> On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> > This patch implements get value domctl interface for MBA.
> >
> > Signed-off-by: Yi Sun
> > ---
>
> ...
>
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -1144,6 +114
On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> This patch implements get value domctl interface for MBA.
>
> Signed-off-by: Yi Sun
> ---
...
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1144,6 +1144,7 @@ struct xen_domctl_psr_alloc_op {
> #define XEN_DOMCTL
Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
check for Xen here when vcpu number is more than 255.
Signed-off-by: Lan Tianyu
---
hw/i386/pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5943539..fc17885 100644
--- a/hw/i
On 08/16/2017 02:16 AM, Tamas K Lengyel wrote:
> On Tue, Aug 15, 2017 at 2:06 AM, Jan Beulich wrote:
> On 14.08.17 at 17:53, wrote:
>>> On Tue, Aug 8, 2017 at 2:27 AM, Alexandru Isaila
>>> wrote:
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,6
flight 112648 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 47 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 111514
Tests which did
Hi,
Thank You for the reply.
We are trying to learn virtualization done in xen. If we are doing any
significant work in this, we will be happy to contribute.
regards,
Ajmal
On Thu, Aug 10, 2017 at 5:11 PM, Oleksandr Andrushchenko wrote:
> Hi,
>
> On 08/10/2017 12:03 PM, ajmalmalib4u wrote:
>
>
In psr.c, we defined some macros but the coding style is not good.
Use '(1u << X)' to replace '(1<
---
xen/arch/x86/psr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 9ce8f17..3622de0 100644
--- a/xen/arch/x86/psr.c
+++ b/x
In order to analyze PI blocking list operation frequence and obtain
the list length, add some relevant events to xentrace and some
associated code in xenalyze.
Signed-off-by: Chao Gao
---
v5:
- Put pi list operation under HW events and get rid of ASYNC stuff
- generate scatterplot of pi list le
This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
how many entries are on the pi blocking list.
Signed-off-by: Chao Gao
---
v5:
- introduce two functions for adding or removing vcpus from pi blocking list.
- check the sanity of vcpu count on pi blocking list
v4:
- non-t
Changes in v5:
- In patch 1, add check the sanity of vcpus count on pi blocking list
and also drop George's Reviewed-by.
- In patch 3, introduce a new function to find proper pCPU to accept
the blocked vcpu.
- In patch 4, add support of tracking the operations on pi blocking list
and gener
This number is used to calculate the average vcpus per pcpu ratio.
Signed-off-by: Chao Gao
Acked-by: Jan Beulich
---
v4:
- move the place we increase/decrease the hvm vcpu number to
hvm_vcpu_{initialise, destory}
---
xen/arch/x86/hvm/hvm.c| 6 ++
xen/include/asm-x86/hvm/hvm.h | 3
Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
too many vCPUs are blocked on a given pCPU, it will incur that the list
grows too long. After a simple analysis, there are 32k domains and
128 vcpu per domain, thus about 4M vCPUs may be blocked in one pCPU's
PI blocking list. When
The problem is for a VF of RC integrated PF (e.g. PF's BDF is
00:02.0), we would wrongly use 00:00.0 to search VT-d unit.
If a PF is an extended function, the BDF of a traditional function
within the same device should be used to search VT-d unit. Otherwise,
the real BDF of PF should be used. Acco
flight 112647 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112647/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-
On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> This patch implements get HW info flow for MBA including its callback
> function and sysctl interface.
>
> Signed-off-by: Yi Sun
> ---
> v1:
> - sort 'PSR_INFO_IDX_' macros as feature.
> (suggested by Chao Peng)
> - rename 'PSR_INFO
Hey Jens,
Please git pull the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.13
which has two fixes, both of them spotted by Amazon.
1) Fix in Xen-blkfront caused by the re-write in 4.8 time-frame.
2) Fix in the xen_biovec_phys_mergeable whi
On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> This patch implements main data structures of MBA.
>
> Like CAT features, MBA HW info has cos_max which means the max cos
> registers number, and thrtl_max which means the max throttle value
Similarly, there is no existence of 'cos register', 'co
On 17-08-15 11:08:32, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 03:41:40PM +0800, Yi Sun wrote:
> > +# Overview
> > +
> > +The Memory Bandwidth Allocation (MBA) feature provides indirect and
> > approximate
> > +control over memory bandwidth available per-core. This feature provides OS/
> > +hyperv
On 17-08-15 11:12:36, Wei Liu wrote:
> You forgot to CC XSM maintainer. I have done that for you.
>
Thank you!
> On Wed, Aug 09, 2017 at 03:41:41PM +0800, Yi Sun wrote:
> > This patch renames PSR sysctl/domctl interfaces and related xsm policy to
> > make them be general for all resource allocati
> -enum cbm_type {
> -PSR_CBM_TYPE_L3,
> -PSR_CBM_TYPE_L3_CODE,
> -PSR_CBM_TYPE_L3_DATA,
> -PSR_CBM_TYPE_L2,
> -PSR_CBM_TYPE_UNKNOWN,
> +enum psr_val_type {
> +PSR_VAL_TYPE_L3,
> +PSR_VAL_TYPE_L3_CODE,
> +PSR_VAL_TYPE_L3_DATA,
> +PSR_VAL_TYPE_L2,
> +PSR_VAL_T
flight 112646 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112646/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112610
Tests which did not succee
On Fri, 11 Aug 2017 14:07:14 +0200
Peter Zijlstra wrote:
> It goes like:
>
> CPU0CPU1
>
> unhook page
> cli
> traverse page tables
> TLB invalidate --->
> sti
>
This run is configured for baseline tests only.
flight 71977 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71977/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6b3d753f98118ee547ae935b347f4f00fa67e7c
baseline v
On Tue, Aug 15, 2017 at 2:06 AM, Jan Beulich wrote:
On 14.08.17 at 17:53, wrote:
>> On Tue, Aug 8, 2017 at 2:27 AM, Alexandru Isaila
>> wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs
On Sun, 6 Aug 2017, Mikko Rapeli wrote:
> xen/interface/xen.h is not exported from kernel headers so remove the
> dependency and provide needed defines for domid_t and xen_pfn_t if they
> are not already defined by some other e.g. Xen specific headers.
>
> Suggested by Andrew Cooper on lkml messa
flight 112643 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112643/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112637
pass in 112643
test-armhf-armhf-xl-r
On 15/08/2017 23:25, Stefano Stabellini wrote:
> On Tue, 15 Aug 2017, Julien Grall wrote:
>> On 14/08/17 22:03, Sergej Proskurin wrote:
>>> Hi Julien,
>>>
>>> On 08/14/2017 07:37 PM, Julien Grall wrote:
Hi Sergej,
On 09/08/17 09:20, Sergej Proskurin wrote:
> +/*
> + *
On Tue, 15 Aug 2017, Julien Grall wrote:
> On 14/08/17 22:03, Sergej Proskurin wrote:
> > Hi Julien,
> >
> > On 08/14/2017 07:37 PM, Julien Grall wrote:
> > > Hi Sergej,
> > >
> > > On 09/08/17 09:20, Sergej Proskurin wrote:
> > > > +/*
> > > > + * According to to ARM DDI 0487B.a J1-5927,
On Wed, 9 Aug 2017, Sergej Proskurin wrote:
> The current implementation of GENMASK is capable of creating bitmasks of
> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
> create masks for 64-bit values on AArch32 as well, in this commit we
> introduce the GENMASK_ULL bit operat
On Tue, 15 Aug 2017, Rajiv Ranganath wrote:
> On Tue, Aug 15 2017 at 06:23:07 AM, Stefano Stabellini
> wrote:
> > Thank you for the patch. Usually the description that you sent in the
> > previous email is written here.
> >
> > I like the build.sh changes and I think introducing init/glide.yaml i
flight 112642 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112642/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> socket.
>
> For passive sockets, check whether we have already pre-allocated an
> active socket for the pur
flight 112644 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112644/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6b3d753f98118ee547ae935b347f4f00fa67e7c
baseline version:
ovmf 4ad5f597153c7cb20a968
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> For active sockets, check the indexes and use the inflight_conn_req
> waitqueue to wait.
>
> For passive sockets if an accept is outstanding
> (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking
> at bedata->rsp[req_id]. If so
flight 112645 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112645/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 24635d9265e70b2d75a17f2cfc0c2ca0fad5843b
baseline version:
xtf 8956f82ce1321b89deda68
On Tue, Aug 15, 2017 at 02:07:51PM +0200, Igor Mammedov wrote:
> On Tue, 15 Aug 2017 12:15:48 +0100
> Anthony PERARD wrote:
>
> > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > set, but this was done only when ACPI tables are built which is not
> > needed for a Xen g
flight 112654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112654/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
flight 112641 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 112544
test-amd64-amd64-x
Hi all,
On 08/09/2017 10:20 AM, Sergej Proskurin wrote:
> The current implementation of GENMASK is capable of creating bitmasks of
> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
> create masks for 64-bit values on AArch32 as well, in this commit we
> introduce the GENMASK_U
Hi Julien,
On 08/15/2017 12:13 PM, Julien Grall wrote:
>
>
> On 14/08/17 22:03, Sergej Proskurin wrote:
>> Hi Julien,
>>
>> On 08/14/2017 07:37 PM, Julien Grall wrote:
>>> Hi Sergej,
>>>
>>> On 09/08/17 09:20, Sergej Proskurin wrote:
+/*
+ * According to to ARM DDI 0487B.a J1-5
On 15/08/17 15:42, Jan Beulich wrote:
> This shrinks the size from 48 to 40 bytes bytes on 64-bit builds.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -185,7 +185,12 @@ struct active_grant_entry {
> grant_ref_t trans_gref;
> st
On 15/08/17 15:42, Jan Beulich wrote:
> Also adjust formatting of nearby code.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 15/08/17 15:41, Jan Beulich wrote:
> They're private to grant_table.c.
>
> Signed-by: Jan Beulich
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -158,7 +158,24 @@ shared_entry_header(struct grant_table *
>
> /* Active grant entry - used for shadowing GTF_permit_acce
On 15/08/17 15:41, Jan Beulich wrote:
> While benign to 32-bit arches, this shrinks the size from 56 to 48
> bytes on 64-bit ones (while still leaving a 16-bit hole).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
There is some follow-on is_sub_page type cleanup you could do,
especia
On 15/08/17 15:40, Jan Beulich wrote:
> They're violating name space rules, and we don't really need them. When
> followed by "gnttab_", also drop that.
>
> Signed-by: Jan Beulich
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -233,8 +233,9 @@ static inline void active_en
On 15/08/17 15:40, Jan Beulich wrote:
> In particular use grant_ref_t and grant_handle_t where appropriate.
> Also switch other nearby type uses to their canonical variants where
> appropriate and introduce INVALID_MAPTRACK_HANDLE.
>
> Signed-by: Jan Beulich
Reviewed-by: Andrew Cooper
This need
On 15/08/17 15:39, Jan Beulich wrote:
> @@ -422,8 +422,13 @@ get_maptrack_handle(
> /*
> * If we've run out of frames, try stealing an entry from another
> * VCPU (in case the guest isn't mapping across its VCPUs evenly).
> + * Also use this path in case we're out of memory, to
flight 112638 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
On 15/08/17 15:38, Jan Beulich wrote:
> Holding any lock while accessing the maptrack entry fields is
> pointless, as these entries are protected by their associated active
> entry lock (which is being acquired later, before re-validating the
> fields read without holding the lock).
>
> Signed-off-
On 15/08/17 17:59, Jan Beulich wrote:
On 15.08.17 at 17:52, wrote:
>> On 15/08/17 17:45, Jan Beulich wrote:
>> On 14.08.17 at 09:08, wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -41,6 +41,7 @@ string_param("console", opt_console);
/*
On 15/08/17 17:31, Jan Beulich wrote:
On 14.08.17 at 09:08, wrote:
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -226,6 +226,10 @@ SECTIONS
>> __start_schedulers_array = .;
>> *(.data.schedulers)
>> __end_schedulers_array = .;
>> + . = ALI
>>> On 15.08.17 at 17:57, wrote:
> On 15/08/17 17:39, Jan Beulich wrote:
> On 14.08.17 at 09:08, wrote:
>>> +struct xen_sysctl_set_parameter {
>>> +XEN_GUEST_HANDLE_64(char) params; /* IN: pointer to parameters.
>>> */
>>> +uint16_t size; /* IN: size of
On 15/08/17 14:49, Jan Beulich wrote:
> Processing of transitive grants must not use the fast path, or else
> reference counting breaks due to the skipped recursive call to
> __acquire_grant_for_copy() (its __release_grant_for_copy()
> counterpart occurs independent of original pin count). Furtherm
flight 112651 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112651/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
>>> On 15.08.17 at 17:52, wrote:
> On 15/08/17 17:45, Jan Beulich wrote:
> On 14.08.17 at 09:08, wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -41,6 +41,7 @@ string_param("console", opt_console);
>>> /* boots. Any other value, or omitting the
On 15/08/17 17:39, Jan Beulich wrote:
On 14.08.17 at 09:08, wrote:
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>> @@ -1096,6 +1096,23 @@ struct xen_sysctl_livepatch_op {
>> typedef struct xen_sysctl_livepatch_op xen_sysctl_livepatch_op_t;
>> DEFINE_XEN_GUEST_HA
>>> On 14.08.17 at 16:23, wrote:
> The only way alloc_boot_pages will return 0 is during the error case.
> Although, Xen will panic in the error path. So the check in the caller
> is pointless.
>
> Looking at the loop, my understanding is it will try to allocate in
> smaller chunk if a bigger chu
On 15/08/17 17:45, Jan Beulich wrote:
On 14.08.17 at 09:08, wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -41,6 +41,7 @@ string_param("console", opt_console);
>> /* boots. Any other value, or omitting the char, enables
>> auto-switch
>> */
>>
>>> On 14.08.17 at 09:08, wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -41,6 +41,7 @@ string_param("console", opt_console);
> /* boots. Any other value, or omitting the char, enables auto-switch
> */
> static unsigned char __read_mostly opt_conswitch
>>> On 14.08.17 at 09:08, wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -1096,6 +1096,23 @@ struct xen_sysctl_livepatch_op {
> typedef struct xen_sysctl_livepatch_op xen_sysctl_livepatch_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_sysctl_livepatch_op_t);
>
> +/*
>
On 15/08/17 14:49, Jan Beulich wrote:
> @@ -2608,7 +2610,7 @@ static long gnttab_copy(
> {
> if ( i && hypercall_preempt_check() )
> {
> -rc = i;
> +rc = count - i;
Somewhere, probably as a comment for gnttab_copy(), we should have a
comment explainin
>>> On 14.08.17 at 09:08, wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -226,6 +226,10 @@ SECTIONS
> __start_schedulers_array = .;
> *(.data.schedulers)
> __end_schedulers_array = .;
> + . = ALIGN(POINTER_ALIGN);
> + __param_start = .
>>> On 14.08.17 at 09:08, wrote:
> In order to support generic parameter parsing carve out the parser from
> _cmdline_parse(). As this generic function might be called after boot
> remove the __init annotations from all called sub-functions.
>
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian J
On Mon, Aug 14, 2017 at 06:58:13PM +0100, Julien Grall wrote:
> Hi,
>
> On 14/08/17 00:20, osstest service owner wrote:
> > flight 112618 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/112618/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are bloc
>>> On 15.08.17 at 17:03, wrote:
> I can switch x86 only back to "normal" types but then we also have this
> in patch 7:
>
> static void check_and_stop_scrub(struct page_info *head)
> {
> if ( head->u.free.scrub_state == BUDDY_SCRUBBING )
> {
> typeof(head->u.free) pgfree;
>
>
On 08/15/2017 10:52 AM, Julien Grall wrote:
> Hi Jan,
>
> On 15/08/17 15:51, Jan Beulich wrote:
> On 15.08.17 at 16:41, wrote:
>>> On 08/15/2017 04:18 AM, Jan Beulich wrote:
>>> On 14.08.17 at 16:29, wrote:
> On 08/14/2017 06:37 AM, Jan Beulich wrote:
> On 08.08.17 at 23:45,
On Tue, Aug 15, 2017 at 7:47 AM, Daniel Micay wrote:
> On 15 August 2017 at 10:20, Thomas Garnier wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>>>
>>> * Thomas Garnier wrote:
>>>
> Do these changes get us closer to being able to build the kernel as truly
> position i
On Tue, Aug 15, 2017 at 02:54:07PM +0200, Juergen Gross wrote:
> On 14/08/17 14:46, Jan Beulich wrote:
> On 14.08.17 at 09:08, wrote:
> >> --- a/xen/common/kernel.c
> >> +++ b/xen/common/kernel.c
> >> optval[-1] = '\0';
> >> +break;
> >
> > Why? Appli
On 15 August 2017 at 10:20, Thomas Garnier wrote:
> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>>
>> * Thomas Garnier wrote:
>>
>>> > Do these changes get us closer to being able to build the kernel as truly
>>> > position independent, i.e. to place it anywhere in the valid x86-64
>>>
Hi Jan,
On 15/08/17 15:51, Jan Beulich wrote:
On 15.08.17 at 16:41, wrote:
On 08/15/2017 04:18 AM, Jan Beulich wrote:
On 14.08.17 at 16:29, wrote:
On 08/14/2017 06:37 AM, Jan Beulich wrote:
On 08.08.17 at 23:45, wrote:
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -88,
>>> On 15.08.17 at 16:41, wrote:
> On 08/15/2017 04:18 AM, Jan Beulich wrote:
> On 14.08.17 at 16:29, wrote:
>>> On 08/14/2017 06:37 AM, Jan Beulich wrote:
>>> On 08.08.17 at 23:45, wrote:
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -88,7 +88,15 @@
This shrinks the size from 48 to 40 bytes bytes on 64-bit builds.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -185,7 +185,12 @@ struct active_grant_entry {
grant_ref_t trans_gref;
struct domain *trans_domain;
unsigned long frame;
Also adjust formatting of nearby code.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -206,11 +206,13 @@ static inline void gnttab_flush_tlb(cons
static inline unsigned int
num_act_frames_from_sha_frames(const unsigned int num)
{
-/* How many f
They're private to grant_table.c.
Signed-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -158,7 +158,24 @@ shared_entry_header(struct grant_table *
/* Active grant entry - used for shadowing GTF_permit_access grants. */
struct active_grant_entry {
-uint32
On 08/15/2017 04:18 AM, Jan Beulich wrote:
On 14.08.17 at 16:29, wrote:
>> On 08/14/2017 06:37 AM, Jan Beulich wrote:
>> On 08.08.17 at 23:45, wrote:
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -88,7 +88,15 @@ struct page_info
/* Page is
While benign to 32-bit arches, this shrinks the size from 56 to 48
bytes on 64-bit ones (while still leaving a 16-bit hole).
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -160,15 +160,15 @@ shared_entry_header(struct grant_table *
struct active_gran
In particular use grant_ref_t and grant_handle_t where appropriate.
Also switch other nearby type uses to their canonical variants where
appropriate and introduce INVALID_MAPTRACK_HANDLE.
Signed-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -96,7 +96,7 @@ struc
They're violating name space rules, and we don't really need them. When
followed by "gnttab_", also drop that.
Signed-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -233,8 +233,9 @@ static inline void active_entry_release(
If rc == GNTST_okay, *page contains
When no memory is available in the hypervisor, rather than immediately
failing the request, try to steal a handle from another vCPU.
Reported-by: George Dunlap
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -411,7 +411,7 @@ get_maptrack_handle(
Holding any lock while accessing the maptrack entry fields is
pointless, as these entries are protected by their associated active
entry lock (which is being acquired later, before re-validating the
fields read without holding the lock).
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
>>> On 15.08.17 at 16:08, wrote:
> On Tuesday, 15 August 2017 11:43:59 PM AEST Jan Beulich wrote:
>> XSA-226 went out with just a workaround patch. The pair of patches
>> here became ready too late to be reasonably included in the XSA.
>> Nevertheless they aim at fixing the underlying issues, idea
On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
>> > Do these changes get us closer to being able to build the kernel as truly
>> > position independent, i.e. to place it anywhere in the valid x86-64 address
>> > space? Or any other advantages?
>>
>> Yes, PIE al
1: drop useless locking
2: avoid spurious maptrack handle allocation failures
3: type adjustments
4: drop pointless leading double underscores
5: re-arrange struct active_grant_entry
6: move GNTPIN_* out of header file
7: use DIV_ROUND_UP() instead of open-coding it
8: drop struct active_grant_entr
On Tuesday, 15 August 2017 11:43:59 PM AEST Jan Beulich wrote:
> XSA-226 went out with just a workaround patch. The pair of patches
> here became ready too late to be reasonably included in the XSA.
> Nevertheless they aim at fixing the underlying issues, ideally making
> the workaround unnecessary
On 15/08/17 14:56, Jan Beulich wrote:
On 15.08.17 at 14:30, wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -1731,31 +1731,25 @@ gnttab_query_size(
>> XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
>> {
>> struct gnttab_query_s
On 08/09/2017 03:41 AM, Yi Sun wrote:
This patch renames PSR sysctl/domctl interfaces and related xsm policy to
make them be general for all resource allocation features but not only
for CAT. Then, we can resuse the interfaces for all allocation features.
Basically, it changes 'cat' to 'alloc'.
>>> On 15.08.17 at 14:30, wrote:
> Remove the opencoded rcu_lock_domain_by_any_id(). Drop the PIN_FAIL()s and
> return GNTST_* values directly.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one optional extra request:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant
On 11/08/17 14:12, Jan Beulich wrote:
> Reported-by: Julien Grall
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 15.08.17 at 14:30, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1731,31 +1731,25 @@ gnttab_query_size(
> XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
> {
> struct gnttab_query_size op;
> -struct domain *d;
> -int r
>>> On 15.08.17 at 14:30, wrote:
> Drop pointless debugging messages, and reduce variable scope.
... and correct the type of an induction variable.
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists
>>> On 15.08.17 at 14:30, wrote:
> * Drop trailing whitespace
> * Style corrections
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen
>>> On 15.08.17 at 14:30, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2345,6 +2345,12 @@ __acquire_grant_for_copy(
> * non-zero refcount and hence a valid owner.
> */
> ASSERT(td);
> +
> +if ( td != rd )
> +{
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-12855 / XSA-230
version 3
grant_table: possibly premature clearing of GTF_writing / GTF_reading
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
Processing of transitive grants must not use the fast path, or else
reference counting breaks due to the skipped recursive call to
__acquire_grant_for_copy() (its __release_grant_for_copy()
counterpart occurs independent of original pin count). Furthermore
after re-acquiring temporarily dropped loc
On 15/08/17 14:46, Jan Beulich wrote:
On 15.08.17 at 15:13, wrote:
>> timer_deadline is only ever updated via this_cpu() in timer_softirq_action(),
>> so is not going to change behind the back of the currently running cpu.
>>
>> Update hpet_broadcast_{enter,exit}() to cache the value in a loc
There is no guarantee that the compiler would actually translate them
to branches instead of calls, so only ones with a known recursion limit
are okay:
- __release_grant_for_copy() can call itself only once, as
__acquire_grant_for_copy() won't permit use of multi-level transitive
grants,
- __ac
>>> On 15.08.17 at 15:13, wrote:
> timer_deadline is only ever updated via this_cpu() in timer_softirq_action(),
> so is not going to change behind the back of the currently running cpu.
>
> Update hpet_broadcast_{enter,exit}() to cache the value in a local variable to
> avoid the repeated RELOC_
1 - 100 of 154 matches
Mail list logo
