flight 145025 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145025/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144990
flight 145032 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145032/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec8c74e8bcc66a43ff766254e68b0504f68e024f
baseline version:
ovmf
On Thu, Dec 19, 2019 at 4:01 PM Stefano Stabellini
wrote:
>
> On Thu, 19 Dec 2019, Julien Grall wrote:
> > > > In fact most of people on Arm are using GRUB rather than EFI directly as
> > > > this is more friendly to use.
> > > >
> > > > Regarding the devicetree, Xen and Linux will completely
flight 145042 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145042/
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
flight 145017 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145017/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144717
test-amd64-i386-xl-pvshim12
flight 145006 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145006/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
Similarly to PV vTSC emulation, optimize HVM side for consistency
and scalability by dropping a spinlock protecting a single variable.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/hvm/vpt.c| 19 ---
xen/include/asm-x86/hvm/vpt.h | 5 ++---
2 files changed, 10
The only invalid value mentioned in Hyper-V TLFS 5.0c is 0. Michael
Kelley confirmed that 0x was never used [0].
[0] https://lists.xen.org/archives/html/xen-devel/2019-12/msg01564.html
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/time.c | 13 -
1 file changed, 4
On Fri, Dec 20, 2019 at 07:15:33PM +, Julien Grall wrote:
> Hi Pawel,
>
> Thank you for fixing the build.
>
> On 20/12/2019 18:23, Pawel Wieczorkiewicz wrote:
> > There was a bunch of typos (s/actions/action/) as well as one missing
> > config.h target dependency. Also, xen_expectation
flight 145033 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145033/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 7 xen-build/dist-test fail REGR. vs. 144983
build-amd64
On Fri, Dec 20, 2019 at 08:04:12PM +, Andrew Cooper wrote:
> On 20/12/2019 20:02, Wei Liu wrote:
> > On Fri, 20 Dec 2019 at 19:57, Andrew Cooper
> > wrote:
> >> On 20/12/2019 19:47, Wei Liu wrote:
> >>> Fixes: 685d16bd5 (x86: implement Hyper-V clock source)
> >>> Signed-off-by: Wei Liu
>
On 20/12/2019 20:02, Wei Liu wrote:
> On Fri, 20 Dec 2019 at 19:57, Andrew Cooper wrote:
>> On 20/12/2019 19:47, Wei Liu wrote:
>>> Fixes: 685d16bd5 (x86: implement Hyper-V clock source)
>>> Signed-off-by: Wei Liu
>>> ---
>>> I discover this stupid mistake when I work on extracting common code
On Fri, 20 Dec 2019 at 19:57, Andrew Cooper wrote:
>
> On 20/12/2019 19:47, Wei Liu wrote:
> > Fixes: 685d16bd5 (x86: implement Hyper-V clock source)
> > Signed-off-by: Wei Liu
> > ---
> > I discover this stupid mistake when I work on extracting common code
> > from viridian and the clock source
On 20/12/2019 19:47, Wei Liu wrote:
> Fixes: 685d16bd5 (x86: implement Hyper-V clock source)
> Signed-off-by: Wei Liu
> ---
> I discover this stupid mistake when I work on extracting common code
> from viridian and the clock source implementation.
Does it make a practical difference?
> ---
>
Also add HVCALL_EXT_CALL_QUERY_CAPABILITIES to hyperv-tlfs.h.
HvGetPartitionID was never used in code so just dropped it.
No functional change intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/private.h | 66 -
xen/arch/x86/hvm/viridian/viridian.c|
Use the one defined in hyperv-tlfs.h instead. No functional change
intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/time.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
The Hyper-V clock source and Xen's own viridian code need the same
functionality.
Move the function in viridian/time.c to hyperv.h and use it in both
places.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/time.c | 30 ++--
Wei Liu (4):
x86/viridian: drop duplicate defines from private.h and viridian.c
x86/viridian: drop private copy of HV_REFERENCE_TSC_PAGE in time.c
x86: provide and use hv_tsc_scale
x86: move viridian_guest_os_id_msr to hyperv-tlfs.h
xen/arch/x86/hvm/viridian/private.h | 66
Suggested-by: Paul Durrant
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/viridian/viridian.c| 2 +-
xen/include/asm-x86/guest/hyperv-tlfs.h | 13 +
xen/include/asm-x86/hvm/viridian.h | 18 +++---
3 files changed, 17 insertions(+), 16 deletions(-)
diff --git
Fixes: 685d16bd5 (x86: implement Hyper-V clock source)
Signed-off-by: Wei Liu
---
I discover this stupid mistake when I work on extracting common code
from viridian and the clock source implementation.
---
xen/arch/x86/time.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build/dist-test
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 reproduced problem changeset ***
Bug
Hi Pawel,
Thank you for fixing the build.
On 20/12/2019 18:23, Pawel Wieczorkiewicz wrote:
There was a bunch of typos (s/actions/action/) as well as one missing
config.h target dependency. Also, xen_expectation target has
unnecessary cycle dependency.
I would suggest to mention which commit
On 12/18/19 10:49 PM, Marek Marczykowski-Górecki wrote:
---
drivers/xen/xen-pciback/conf_space.c | 35
drivers/xen/xen-pciback/conf_space.h | 10 +++
.../xen/xen-pciback/conf_space_capability.c | 88 +++
On 20/12/2019 19:04, Julien Grall wrote:
> Hi,
>
> I forgot to mention the type in the commit title:
>
> s/unimplemneted/implemented/
Oops. TYVM. Fixed.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi,
I forgot to mention the type in the commit title:
s/unimplemneted/implemented/
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi,
On 20/12/2019 18:30, Andrew Cooper wrote:
On 20/12/2019 18:24, Ian Jackson wrote:
Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain
types"):
x86 PVH is completely obsolete - it was intended for legacy PVH before that
idea was abandoned. There was an RFC series
Andrew Cooper writes ("Re: [PATCH] libxc/restore: Don't duplicate state in
process_vcpu_basic()"):
> On 20/12/2019 18:22, Ian Jackson wrote:
> > It is not obvious to me that nothing uses the modified fields after
> > process_vcpu_basic has edited things. The ctx of which the vcpu is
> > part is
Andrew Cooper writes ("Re: [PATCH] libxc/migration: Drop unimplemneted domain
types"):
> On 20/12/2019 18:24, Ian Jackson wrote:
> > Could there be any software which uses them ?
>
> Not plausibly, no, given...
>
> > Eg, maybe someone put the RFC series into production ?
>
> ... the rather
On 20/12/2019 18:22, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] libxc/restore: Don't duplicate state in
> process_vcpu_basic()"):
>> vcpu_guest_context_any_t is currently allocated on the stack, and copied from
>> a mutable buffer which is freed immediately after its use here.
>>
>>
On 20/12/2019 18:24, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain
> types"):
>> x86 PVH is completely obsolete - it was intended for legacy PVH before that
>> idea was abandoned. There was an RFC series for ARM in 2015, but there is
>> plenty of
Andrew Cooper writes ("[PATCH] libxc/migration: Drop unimplemneted domain
types"):
> x86 PVH is completely obsolete - it was intended for legacy PVH before that
> idea was abandoned. There was an RFC series for ARM in 2015, but there is
> plenty of outstanding work which hasn't been done yet.
>
There was a bunch of typos (s/actions/action/) as well as one missing
config.h target dependency. Also, xen_expectation target has
unnecessary cycle dependency.
Signed-off-by: Pawel Wieczorkiewicz
---
xen/test/livepatch/Makefile | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
Andrew Cooper writes ("[PATCH] libxc/restore: Don't duplicate state in
process_vcpu_basic()"):
> vcpu_guest_context_any_t is currently allocated on the stack, and copied from
> a mutable buffer which is freed immediately after its use here.
>
> Mutate the buffer in place instead of duplicating
Andrew Cooper writes ("[PATCH] libxc/migration: Rename TSC_INFO to
X86_TSC_INFO"):
> This record is specific to x86, and should have had a prefix to being with.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Andrew Cooper writes ("[PATCH] docs/migration: Remove numbering for typical
records"):
> The numbers aren't referenced directly, and explicit numbering makes an
> unnecesserily large diff when inserting something new in the middle.
Acked-by: Ian Jackson
On Fri, Dec 20, 2019 at 11:00 AM Andrew Cooper
wrote:
>
> On 20/12/2019 17:50, Tamas K Lengyel wrote:
> > On Fri, Dec 20, 2019 at 10:47 AM Andrew Cooper
> > wrote:
> >> On 20/12/2019 17:36, Tamas K Lengyel wrote:
> >>> On Fri, Dec 20, 2019 at 10:32 AM Andrew Cooper
> >>> wrote:
> On
On 20/12/2019 17:50, Tamas K Lengyel wrote:
> On Fri, Dec 20, 2019 at 10:47 AM Andrew Cooper
> wrote:
>> On 20/12/2019 17:36, Tamas K Lengyel wrote:
>>> On Fri, Dec 20, 2019 at 10:32 AM Andrew Cooper
>>> wrote:
On 20/12/2019 17:27, Tamas K Lengyel wrote:
> On Fri, Dec 20, 2019 at 9:47
On Fri, Dec 20, 2019 at 10:47 AM Andrew Cooper
wrote:
>
> On 20/12/2019 17:36, Tamas K Lengyel wrote:
> > On Fri, Dec 20, 2019 at 10:32 AM Andrew Cooper
> > wrote:
> >> On 20/12/2019 17:27, Tamas K Lengyel wrote:
> >>> On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich wrote:
> On 18.12.2019
On Fri, Dec 20, 2019 at 05:35:02PM +, Andrew Cooper wrote:
> x86 PVH is completely obsolete - it was intended for legacy PVH before that
> idea was abandoned. There was an RFC series for ARM in 2015, but there is
> plenty of outstanding work which hasn't been done yet.
>
> No functional
On 20/12/2019 17:36, Tamas K Lengyel wrote:
> On Fri, Dec 20, 2019 at 10:32 AM Andrew Cooper
> wrote:
>> On 20/12/2019 17:27, Tamas K Lengyel wrote:
>>> On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich wrote:
On 18.12.2019 20:40, Tamas K Lengyel wrote:
> Currently the hvm parameters are only
On Fri, Dec 20, 2019 at 05:05:24PM +0100, Jan Beulich wrote:
> On 18.12.2019 15:42, Wei Liu wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Can this please move ...
>
> > @@ -644,6 +645,103
Hi Andrew,
On 20/12/2019 17:35, Andrew Cooper wrote:
x86 PVH is completely obsolete - it was intended for legacy PVH before that
idea was abandoned. There was an RFC series for ARM in 2015, but there is
plenty of outstanding work which hasn't been done yet.
No functional change. New types
On Fri, Dec 20, 2019 at 10:32 AM Andrew Cooper
wrote:
>
> On 20/12/2019 17:27, Tamas K Lengyel wrote:
> > On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich wrote:
> >> On 18.12.2019 20:40, Tamas K Lengyel wrote:
> >>> Currently the hvm parameters are only accessible via the HVMOP
> >>> hypercalls. By
x86 PVH is completely obsolete - it was intended for legacy PVH before that
idea was abandoned. There was an RFC series for ARM in 2015, but there is
plenty of outstanding work which hasn't been done yet.
No functional change. New types can be (re)introduced with the code which
actually
On 20/12/2019 17:27, Tamas K Lengyel wrote:
> On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich wrote:
>> On 18.12.2019 20:40, Tamas K Lengyel wrote:
>>> Currently the hvm parameters are only accessible via the HVMOP hypercalls.
>>> By
>>> exposing hvm_{get/set}_param it will be possible for VM
This record is specific to x86, and should have had a prefix to being with.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Marek
On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich wrote:
>
> On 18.12.2019 20:40, Tamas K Lengyel wrote:
> > Currently the hvm parameters are only accessible via the HVMOP hypercalls.
> > By
> > exposing hvm_{get/set}_param it will be possible for VM forking to copy the
> > parameters directly into
The numbers aren't referenced directly, and explicit numbering makes an
unnecesserily large diff when inserting something new in the middle.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC:
vcpu_guest_context_any_t is currently allocated on the stack, and copied from
a mutable buffer which is freed immediately after its use here.
Mutate the buffer in place instead of duplicating it.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
flight 145027 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 7 xen-build/dist-test fail REGR. vs. 144983
build-amd64
On 18.12.2019 20:40, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -321,8 +321,7 @@ static void hap_free_p2m_page(struct domain *d, struct
> page_info *pg)
> }
>
> /* Return the size of the pool, rounded up to the nearest MB */
> -static
On 18.12.2019 20:40, Tamas K Lengyel wrote:
> Currently the hvm parameters are only accessible via the HVMOP hypercalls. By
> exposing hvm_{get/set}_param it will be possible for VM forking to copy the
> parameters directly into the clone domain.
Having peeked ahead at patch 17, where this gets
flight 145000 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145000/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 796b380ca7d263ca504b82fe5317a78d3546d537
baseline version:
ovmf
On 17.07.2019 08:47, Jan Beulich wrote:
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
> ^
On 16.09.2019 11:40, Jan Beulich wrote:
> Using memcpy() may result in multiple individual byte accesses
> (dependening how memcpy() is implemented and how the resulting insns,
> e.g. REP MOVSB, get carried out in hardware), which isn't what we
> want/need for carrying out guest insns as correctly
On 20.12.2019 17:01, Andrew Cooper wrote:
> On 20/12/2019 13:41, Jan Beulich wrote:
>> In a pure PV environment (the PV shim in particular) we don't really
>> need emulation of all these. To limit #ifdef-ary utilize some of the
>> CASE_*() macros we have, by providing variants expanding to
>>
On 20/12/2019 16:05, Jan Beulich wrote:
>> +wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr);
>> +
>> +/* Get TSC frequency from Hyper-V */
>> +rdmsrl(HV_X64_MSR_TSC_FREQUENCY, freq);
>> +pts->frequency = freq;
>> +
>> +return freq;
>> +}
>> +
>> +static inline uint64_t
On 18.12.2019 15:42, Wei Liu wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
Can this please move ...
> @@ -644,6 +645,103 @@ static struct platform_timesource __initdata
> plt_xen_timer =
> };
> #endif
>
On 20/12/2019 13:41, Jan Beulich wrote:
> In a pure PV environment (the PV shim in particular) we don't really
> need emulation of all these. To limit #ifdef-ary utilize some of the
> CASE_*() macros we have, by providing variants expanding to
> (effectively) nothing (really a label, which in turn
flight 144995 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144995/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144958
test-armhf-armhf-libvirt-raw 13
On 20/12/2019 13:40, Jan Beulich wrote:
> Since there are many AVX{,2} insns having legacy SIMD counterparts, have
> macros covering both in one go. This (imo) improves readability and helps
> prepare for optionally disabling SIMD support in the emulator.
>
> Signed-off-by: Jan Beulich
Acked-by:
On 20/12/2019 13:40, Jan Beulich wrote:
> It's used only by CASE_SIMD_ALL_FP(), which can equally well be
> implemented in terms of CASE_SIMD_{PACKED,SCALAR}_FP().
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On 20/12/2019 13:39, Jan Beulich wrote:
> Since there are many AVX{,2} insns having legacy MMX and SIMD
> counterparts, have a macro covering all three in one go. This (imo)
> improves readability (simply by the shrunk number of lines) and helps
> prepare for optionally disabling MMX and SIMD
On 19.12.2019 17:03, Igor Druzhinin wrote:
> Now that vtsc_last is the only entity protected by vtsc_lock we can
> simply update it using a single atomic operation and drop the spinlock
> entirely. This is extremely important for the case of running nested
> (e.g. shim instance with lots of vCPUs
On 20/12/2019 13:39, Jan Beulich wrote:
> This (imo) improves readability (simply by the shrunk number of lines)
> and helps prepare for optionally disabling MMX and SIMD support in the
> emulator.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 20/12/2019 14:19, Jan Beulich wrote:
> After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page
> table") and the removal of 32-bit support the function doesn't modify
> state anymore, and hence its name has been misleading. Change its name,
> constify parameters and a local
On 20/12/2019 15:17, Jan Beulich wrote:
> On 04.12.2019 17:20, Roger Pau Monne wrote:
>> Check that the processor to be woken up APIC ID is addressable in the
>> current APIC mode.
>>
>> Note that in practice systems with APIC IDs > 255 should already have
>> x2APIC enabled by the firmware, and
On 04.12.2019 17:20, Roger Pau Monne wrote:
> Check that the processor to be woken up APIC ID is addressable in the
> current APIC mode.
>
> Note that in practice systems with APIC IDs > 255 should already have
> x2APIC enabled by the firmware, and hence this is mostly a safety
> belt.
>
>
On 20.12.2019 15:58, George Dunlap wrote:
> On 12/20/19 2:41 PM, Jan Beulich wrote:
>> On 20.12.2019 15:26, George Dunlap wrote:
>>> On 12/20/19 2:21 PM, Jan Beulich wrote:
In ept_p2m_type_to_flags() passing in type and access as separate
parameters can be considered an optimization, as
On 20/12/2019 14:55, Jan Beulich wrote:
> On 20.12.2019 15:51, Andrew Cooper wrote:
>> On 20/12/2019 14:20, Jan Beulich wrote:
>>> get_page_light()'s use of cmpxchg() is a full barrier already anyway.
>>>
>>> Signed-off-by: Jan Beulich
>> While true, is this actually a clever change to make?
>>
On 20.12.2019 15:54, George Dunlap wrote:
> On 12/20/19 2:52 PM, Jan Beulich wrote:
>> On 20.12.2019 15:47, George Dunlap wrote:
>>> On 12/20/19 2:42 PM, Andrew Cooper wrote:
On 20/12/2019 14:19, Jan Beulich wrote:
> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
On 12/20/19 2:41 PM, Jan Beulich wrote:
> On 20.12.2019 15:26, George Dunlap wrote:
>> On 12/20/19 2:21 PM, Jan Beulich wrote:
>>> In ept_p2m_type_to_flags() passing in type and access as separate
>>> parameters can be considered an optimization, as all callers set the
>>> respective fields in the
On 12/20/19 2:52 PM, Jan Beulich wrote:
> On 20.12.2019 15:47, George Dunlap wrote:
>> On 12/20/19 2:42 PM, Andrew Cooper wrote:
>>> On 20/12/2019 14:19, Jan Beulich wrote:
mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
Fold page_info lock into type_info"), and
On 20.12.2019 15:51, Andrew Cooper wrote:
> On 20/12/2019 14:20, Jan Beulich wrote:
>> get_page_light()'s use of cmpxchg() is a full barrier already anyway.
>>
>> Signed-off-by: Jan Beulich
>
> While true, is this actually a clever change to make?
>
> The implementation of get_page_light()
On 20.12.2019 15:47, George Dunlap wrote:
> On 12/20/19 2:42 PM, Andrew Cooper wrote:
>> On 20/12/2019 14:19, Jan Beulich wrote:
>>> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
>>> Fold page_info lock into type_info"), and the other three never had such
>>> a need, at
On 20/12/2019 14:20, Jan Beulich wrote:
> get_page_light()'s use of cmpxchg() is a full barrier already anyway.
>
> Signed-off-by: Jan Beulich
While true, is this actually a clever change to make?
The implementation of get_page_light() could plausibly change and no
longer be a full barrier,
On 12/20/19 2:42 PM, Andrew Cooper wrote:
> On 20/12/2019 14:19, Jan Beulich wrote:
>> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
>> Fold page_info lock into type_info"), and the other three never had such
>> a need, at least going back as far as 3.2.0.
>>
>>
On 20.12.2019 15:42, Andrew Cooper wrote:
> On 20/12/2019 14:19, Jan Beulich wrote:
>> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
>> Fold page_info lock into type_info"), and the other three never had such
>> a need, at least going back as far as 3.2.0.
>>
>>
From: Juergen Gross
[ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
From: Juergen Gross
[ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
From: Paul Durrant
[ Upstream commit fa2ac657f9783f0891b2935490afe9a7fd29d3fa ]
Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
cache. This cache is destoyed when xen-blkif is unloaded so it is
necessary to wait for the deferred free routine used for such objects to
On 20/12/2019 14:19, Jan Beulich wrote:
> All that really matters is whether writability of a page changes; in
> paticular e.g. page table -> page table (but different levels)
> transitions do not require unmapping the page from the IOMMU again.
>
> Note that the XSA-288 fix did arrange for
On 20.12.2019 15:34, Andrew Cooper wrote:
> On 20/12/2019 13:30, Jan Beulich wrote:
>> The legacy vectors have been actively used on CPU 0 only. CPUs not
>> sharing vector space with CPU 0 can easily re-use them, slightly
>> increasing the relatively scarce resource of total vectors available in
On 20/12/2019 14:19, Jan Beulich wrote:
> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
> Fold page_info lock into type_info"), and the other three never had such
> a need, at least going back as far as 3.2.0.
>
> Signed-off-by: Jan Beulich
These presumably want
On 20.12.2019 15:26, George Dunlap wrote:
> On 12/20/19 2:21 PM, Jan Beulich wrote:
>> In ept_p2m_type_to_flags() passing in type and access as separate
>> parameters can be considered an optimization, as all callers set the
>> respective fields in the entry being updated before the call. Retain
On 20/12/2019 13:55, Jan Beulich wrote:
> There's been effectively no use of the field for HVM.
>
> Also shrink the field to unsigned int, even if this doesn't immediately
> yield any space benefit for the structure itself. The resulting 32-bit
> padding slot can eventually be used for some other
From: Juergen Gross
[ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
From: Paul Durrant
[ Upstream commit fa2ac657f9783f0891b2935490afe9a7fd29d3fa ]
Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
cache. This cache is destoyed when xen-blkif is unloaded so it is
necessary to wait for the deferred free routine used for such objects to
On 20/12/2019 14:25, Jan Beulich wrote:
> To fulfill the "protected" in its name, don't let the real hardware
> values leak. While we could report a control register value expressing
> this (which I would have preferred), unconditionally raise #GP for all
> accesses (in the interest of getting
On 20/12/2019 13:30, Jan Beulich wrote:
> The legacy vectors have been actively used on CPU 0 only. CPUs not
> sharing vector space with CPU 0 can easily re-use them, slightly
> increasing the relatively scarce resource of total vectors available in
> the system.
I suppose this technically
From: Paul Durrant
[ Upstream commit fa2ac657f9783f0891b2935490afe9a7fd29d3fa ]
Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
cache. This cache is destoyed when xen-blkif is unloaded so it is
necessary to wait for the deferred free routine used for such objects to
From: Juergen Gross
[ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
From: Juergen Gross
[ Upstream commit c673ec61ade89bf2f417960f986bc25671762efb ]
When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
From: Paul Durrant
[ Upstream commit fa2ac657f9783f0891b2935490afe9a7fd29d3fa ]
Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
cache. This cache is destoyed when xen-blkif is unloaded so it is
necessary to wait for the deferred free routine used for such objects to
On 20/12/2019 14:21, Wei Liu wrote:
> On Tue, Dec 17, 2019 at 02:49:28PM +, Wei Liu wrote:
>> Signed-off-by: Wei Liu
> This is a trivial patch. I will apply it soon-ish unless I'm told
> otherwise.
Acked-by: Andrew Cooper
___
Xen-devel mailing
On 12/20/19 2:21 PM, Jan Beulich wrote:
> In ept_p2m_type_to_flags() passing in type and access as separate
> parameters can be considered an optimization, as all callers set the
> respective fields in the entry being updated before the call. Retain
> this behavior but add assertions.
>
>
To fulfill the "protected" in its name, don't let the real hardware
values leak. While we could report a control register value expressing
this (which I would have preferred), unconditionally raise #GP for all
accesses (in the interest of getting this done).
Signed-off-by: Jan Beulich
---
v3:
In ept_p2m_type_to_flags() passing in type and access as separate
parameters can be considered an optimization, as all callers set the
respective fields in the entry being updated before the call. Retain
this behavior but add assertions.
Signed-off-by: Jan Beulich
---
On Tue, Dec 17, 2019 at 02:49:28PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
This is a trivial patch. I will apply it soon-ish unless I'm told
otherwise.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
All that really matters is whether writability of a page changes; in
paticular e.g. page table -> page table (but different levels)
transitions do not require unmapping the page from the IOMMU again.
Note that the XSA-288 fix did arrange for PGT_none pages not needing
special consideration here.
1 - 100 of 161 matches
Mail list logo
