Hi,
On 20/12/2019 00:01, 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 ignore the
memory nodes in Xen if using EFI
On 20.12.2019 00:15, Andrew Cooper wrote:
> On 19/12/2019 11:35, Jan Beulich wrote:
> XENVER_changeset
> XENVER_commandline
> XENVER_build_id
>
> Return a more customer friendly empty string instead of ""
> which would be shown in tools like dmidecode.>
I th
On 19.12.19 17:42, Sergey Dyasli wrote:
On 18/12/2019 09:24, Jürgen Groß wrote:
On 17.12.19 15:08, Sergey Dyasli wrote:
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Rough edges in the
On Thu, Dec 19, 2019 at 01:04:12PM +, Andrew Cooper wrote:
> convert-legacy-stream is only used for incomming migration from pre Xen 4.7,
> and verify-stream-v2 appears to only be used by me during migration
> development - it is little surprise that they missed the main converstion
> effort in
On 19.12.2019 12:43, Jan Beulich wrote:
> On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
>> This patch aims to sanitize indexes, potentially guest provided
>> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>>
>> Requested-by: Jan Beulich
>> Signed-off-by: Alexandru Isaila
>> ---
>> CC:
flight 144999 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144999/
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 20.12.2019 10:09, Alexandru Stefan ISAILA wrote:
>
>
> On 19.12.2019 12:43, Jan Beulich wrote:
>> On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
>>> This patch aims to sanitize indexes, potentially guest provided
>>> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>>>
>>> Requested-by:
On 19.12.2019 18:47, Sergey Kovalev wrote:
> When using DRAKVUF (or another system using altp2m with shadow pages similar
> to what is described in
> https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
> after a breakpoint is hit the system switches to the default
> unrestricted
On 19.12.2019 22:08, Eslam Elnikety wrote:
> On 18.12.19 12:49, Jan Beulich wrote:
>> On 18.12.2019 02:32, Eslam Elnikety wrote:
>>> Decouple the microcode referencing mechanism when using GRUB to that
>>> when using EFI. This allows us to avoid the "unspecified effect" of
>>> using ` | scan` along
On 19.12.2019 22:25, Eslam Elnikety wrote:
> On 18.12.19 13:05, Jan Beulich wrote:
>> On 18.12.2019 02:32, Eslam Elnikety wrote:
>>> @@ -725,7 +701,7 @@ static int __init microcode_init(void)
>>>*/
>>> if ( ucode_blob.size )
>>> {
>>> -xfree(ucode_blob.data);
>>> +
On 19.12.2019 23:11, Eslam Elnikety wrote:
> On 18.12.19 13:42, Jan Beulich wrote:
>> On 18.12.2019 02:32, Eslam Elnikety wrote:
>>> +
>>> +
>>> +Xen can bundle microcode updates within its image. This support is
>>> conditional
>>> +on the build configu
On 17/12/2019 18:06, Boris Ostrovsky wrote:
>
>
>> On Dec 17, 2019, at 9:08 AM, Sergey Dyasli wrote:
>>
>> This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
>> CONFIG_KASAN=y. It has been used internally for some time now with good
>> results for finding memory corruption is
On 20.12.19 11:12, Jan Beulich wrote:
On 19.12.2019 23:11, Eslam Elnikety wrote:
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
+
+
+Xen can bundle microcode updates within its image. This support is conditional
+on
On 20.12.2019 11:34, Jürgen Groß wrote:
> On 20.12.19 11:12, Jan Beulich wrote:
>> On 19.12.2019 23:11, Eslam Elnikety wrote:
>>> On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
> +
> +
> +Xen can bundle m
On 19.12.2019 18:38, Paul Durrant wrote:
> ...for patches not (yet) upstream.
>
> This patch is simply adding a comment to reserve save record number space
> to avoid the risk of clashes between existent downstream changes made by
> Amazon and future upstream changes which may be incompatible.
>
osstest service owner writes ("[osstest test] 144980: regressions - FAIL"):
> flight 144980 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144980/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-
On 18.12.19 19:37, SeongJae Park wrote:
From: SeongJae Park
A driver's 'reclaim_memory' callback can race with 'probe' or 'remove'
because it will be called whenever memory pressure is detected. To
avoid such race, this commit embeds a spinlock in each 'xenbus_device'
and make 'xenbus' to hold
On 17.12.19 21:53, Aditya Pakki wrote:
gnttab_request_version() always sets the gnttab_interface variable
and the assertions to check for empty gnttab_interface is unnecessary.
The patch eliminates multiple such assertions.
Signed-off-by: Aditya Pakki
Reviewed-by: Juergen Gross
Juergen
__
On 20.12.2019 11:39, Jan Beulich wrote:
> On 20.12.2019 10:09, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 19.12.2019 12:43, Jan Beulich wrote:
>>> On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[
Andrew Cooper writes ("[PATCH] libxc/restore: Fix data auditing in
handle_x86_pv_info()"):
> handle_x86_pv_info() has a subtle bug. It uses an 'else if' chain with a
> clause in the middle which doesn't exit unconditionally. In practice, this
> means that when restoring a 32bit PV guest, later s
Andrew Cooper writes ("[PATCH] libxc/restore: Fix data auditing in
handle_x86_pv_vcpu_blob()"):
> The current logic only works by chance, in that XSAVE records also tend to be
> a multiple of 128. Implement the missing logic for XSAVE.
Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH 2/1] libxc: Drop other examples of the 'goto x; }
else if' antipattern"):
> None of these are buggy, but the resulting code is more robust.
>
> No functional change.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-d
On 20.12.2019 12:49, Alexandru Stefan ISAILA wrote:
>
>
> On 20.12.2019 11:39, Jan Beulich wrote:
>> On 20.12.2019 10:09, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 19.12.2019 12:43, Jan Beulich wrote:
On 19.12.2019 10:42, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize i
On 09.12.19 21:14, Nathan Chancellor wrote:
Clang warns:
../drivers/block/xen-blkfront.c:1117:4: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
nr_parts = PARTS_PER_DISK;
^
../drivers/block/xen-blkfront.c:1
On 19/12/2019 07:42, Juergen Gross wrote:
> Support for debugging the hypervisor of guests via gdb/gdbsx should be
> configurable.
>
> Changes in V3:
> - remove possibility to access hypervisor memory via gdbsx domctl
> - default gdbsx support to on
> - some code moving
>
> Changes in V2:
> - split
On 11.12.19 16:29, Paul Durrant wrote:
Patch #1 is clean-up for an apparent mis-feature.
Paul Durrant (4):
xenbus: move xenbus_dev_shutdown() into frontend code...
xenbus: limit when state is forced to closed
xen/interface: re-define FRONT/BACK_RING_ATTACH()
xen-blkback: support dyna
Andrew Cooper writes ("[PATCH] tools/libxc: Drop unused xc_compression_*()"):
> There have been no users of the xc_compression_*() interface since Migration
> v2 replaced legacy migration (2016, c/s b15bc4345).
Acked-by: Ian Jackson
Taking you at your word that this is unused - I haven't checked
On 19/12/2019 07:42, Juergen Gross wrote:
> Some code is not needed with CONFIG_CRASH_DEBUG, so only include it if
> CONFIG_CRASH_DEBUG is defined.
s/with/without/ ? and I presume you are referring to debugger_trap_entry() ?
~Andrew
___
Xen-devel maili
On 20.12.19 13:52, Andrew Cooper wrote:
On 19/12/2019 07:42, Juergen Gross wrote:
Some code is not needed with CONFIG_CRASH_DEBUG, so only include it if
CONFIG_CRASH_DEBUG is defined.
s/with/without/ ? and I presume you are referring to debugger_trap_entry() ?
Yes and yes.
Juergen
__
On 17.12.19 21:53, Aditya Pakki wrote:
gnttab_request_version() always sets the gnttab_interface variable
and the assertions to check for empty gnttab_interface is unnecessary.
The patch eliminates multiple such assertions.
Signed-off-by: Aditya Pakki
Pushed to xen/tip.git for-linus-5.5b
Ju
flight 145013 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145013/
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
The first two I've been meaning to do for a long time. The 3rd is
(optional) follow-up to a pretty late 4.13 change. The next two
were suggested by Andrew to slightly increase the number of IRQs
we could handle in total, seeing that IRQ vectors are a relatively
scarce resource. The last one is a re
This is to avoid forward declarations of static functions. Beyond the
actual code movement this does
- u8 -> uint8_t,
- convert to Xen style,
- drop unnecessary parentheses and alike,
- strip trailing white space.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -4
This is for it to be next to do_IRQ(). Beyond the actual code movement
this
- drops the leading underscores,
- passes in desc and vector, rather than irq,
- flips the order of two ASSERT()s,
- changes i and sp to unsigned int,
- restricts the scope of d and sp,
- corrects style.
Signed-off-by: Jan
In 5655ce8b1ec2 ("x86/IRQ: make internally used IRQs also honor the
pending EOI stack") it was mentioned that both the check_eoi_deferral
per-CPU variable and the cpu_has_pending_apic_eoi() were added just to
have as little impact on existing behavior as possible, to reduce the
risk of a last minut
There's no reason to have the PIC vectors (which are typically entirely
unused on 64-bit systems anyway) right below the high priority ones. Put
them in the lowest possible range, and shift the dynamic vector range up
accordingly.
Note that irq_move_cleanup_interrupt(), despite using
FIRST_DYNAMIC
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. As a result the legacy vector range simply becomes a
sub-range of the dynamic one,
This is an architectural definition, so move it to x86-defns.h and add
an X86_ prefix. This in particular allows removing the inclusion of
irq_vectors.h by virtually every source file, due to irq.h and
hvm/vmx/vmcs.h having needed to include it: Changes to IRQ vector usage
shouldn't really trigger
On 20/12/2019 13:29, Jan Beulich wrote:
> This is to avoid forward declarations of static functions. Beyond the
> actual code movement this does
> - u8 -> uint8_t,
> - convert to Xen style,
> - drop unnecessary parentheses and alike,
> - strip trailing white space.
>
> Signed-off-by: Jan Beulich
This is in particular helpful for pure PV environments, e.g. the
shim.
1: use CASE_SIMD_PACKED_INT() where possible
2: introduce CASE_SIMD_PACKED_INT_VEX()
3: drop CASE_SIMD_DOUBLE_FP()
4: introduce CASE_SIMD_..._FP_VEX()
5: disable FPU/MMX/SIMD insn emulation when !HVM
Jan
_
On 20/12/2019 13:29, Jan Beulich wrote:
> +for ( i = 0; i < action->nr_guests; i++ )
> +{
> +struct domain *d = action->guest[i];
> +struct pirq *pirq;
> +
> +pirq = pirq_info(d, domain_irq_to_pirq(d, desc->irq));
You could drop one further line by folding this into
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -8528,36 +8528,21 @@ x86
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6010,21 +6010,18 @@ x86_emulate(
CASE_SIMD_PACKED_
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 support in the emulator.
Signed-off-by: Jan Beulich
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch
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 requires passing
-Wno-unused-label to the compil
A few things stumbled across while doing the investigations.
1: relax GDT check in arch_set_info_guest()
2: relax LDT check in arch_set_info_guest()
3: PV: polish pv_set_gdt()
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
On 20/12/2019 13:31, Jan Beulich wrote:
> This is an architectural definition, so move it to x86-defns.h and add
> an X86_ prefix. This in particular allows removing the inclusion of
> irq_vectors.h by virtually every source file, due to irq.h and
> hvm/vmx/vmcs.h having needed to include it: Chang
It is wrong for us to check frames beyond the guest specified limit
(in the native case, other than in the compat one).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -840,6 +840,7 @@ int arch_set_info_guest(
#ifdef CONFIG_PV
mfn_t cr3_mfn;
struc
It is wrong for us to check the base address when there's no LDT in the
first place. Once we don't do this check anymore we can also set the
base address to a non-canonical value when the LDT is empty.
Signed-off-by: Jan Beulich
---
v2: Set v->arch.pv.ldt_base to non-canonical for an empty LDT, p
There's no need to invoke get_page_from_gfn(), and there's also no need
to update the passed in frames[]. Invoke get_page_and_type() directly.
Also make the function's frames[] parameter const, change its return
type to int, and drop the bogus casts from two of its invocations.
Finally a little b
On 20/12/2019 13:29, Jan Beulich wrote:
> In 5655ce8b1ec2 ("x86/IRQ: make internally used IRQs also honor the
> pending EOI stack") it was mentioned that both the check_eoi_deferral
> per-CPU variable and the cpu_has_pending_apic_eoi() were added just to
> have as little impact on existing behavior
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 field. The change in
size makes accesses slightly
flight 144990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144990/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144959
test-amd64-amd64-xl-rtds 18 gues
On 20/12/2019 13:29, Jan Beulich wrote:
> There's no reason to have the PIC vectors (which are typically entirely
> unused on 64-bit systems anyway) right below the high priority ones. Put
> them in the lowest possible range, and shift the dynamic vector range up
> accordingly.
It might be helpful
While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
expensive (but still needed only for the toggle_guest_mode() path), the
effect of the latter on the exit-to-guest path is not insignificant.
Move the logic into toggle_guest_mode(), on the basis that
toggle_guest_pt() will alw
On 12/19/19 7:42 AM, Juergen Gross wrote:
> Some code is not needed with CONFIG_CRASH_DEBUG, so only include it if
> CONFIG_CRASH_DEBUG is defined.
>
> While at it remove CONFIG_HAS_GDBSX as it can easily be replaced by
> CONFIG_CRASH_DEBUG.
>
> Signed-off-by: Juergen Gross
In case you need it
Addressing a few assorted aspects I've noticed during the
investigations / reviews.
1: mod_l_entry() have no need to use __copy_from_user()
2: rename and tidy create_pae_xen_mappings()
3: avoid IOMMU operations in more cases in _get_page_type()
4: drop redundant smp_wmb() from _put_final_page_type
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 variable, and make it return bool.
Also drop the call
get_page_light()'s use of cmpxchg() is a full barrier already anyway.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2746,7 +2746,7 @@ static int _put_final_page_type(struct p
else
{
BUG_ON(rc != -ERESTART);
-smp_wmb();
+/* get_p
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
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2124,13 +2124,10 @@ static i
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.
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
https://lists.xenproject.org/
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
--- a/xen/arch/x86/mm/p2m-ept.c
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: Unc
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.
>
> Signed-o
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 lis
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
complet
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
alloc_xenballooned_pa
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
alloc_xenballooned_pa
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
complet
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 depends
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 this
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
complet
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
alloc_xenballooned_pa
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 f
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 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 ACCESS_ON
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
>>
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
alloc_xenballooned_pa
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
complet
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 PGT_non
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
alloc_xenballooned_pa
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.
>>
>> Signed-off-
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.
>>
>> Signed-off-
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, intr
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 lea
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 the
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() could
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 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 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: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 a
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.
>
> Signed
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 hen
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 variabl
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 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 a
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 suppo
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
Xen-d
1 - 100 of 161 matches
Mail list logo
