On 01.12.2021 16:11, Andrew Cooper wrote:
> On 01/12/2021 09:42, Jan Beulich wrote:
>> The array of IDs is an output.
>>
>> Fixes: 79647c5bc9c6 ("libxc: convert domctl interfaces over to hypercall
>> buffers")
>> Signed-off-by: Jan Beulich
>> ---
>> Clearly the function, including its Python
On 01.12.2021 16:13, Andrew Cooper wrote:
> On 01/12/2021 09:39, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1457,24 +1462,24 @@ static int iommu_get_device_group(
>> if ( !is_iommu_enabled(d) || !ops->get_device_group_id )
>>
flight 166995 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 18 guest-start/debian.repeat fail REGR. vs. 166958
On 01.12.21 22:10, Christophe JAILLET wrote:
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some
open-coded arithmetic in allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Use 'bitmap_copy()' to avoid an explicit
flight 166975 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 22 guest-destroyfail REGR. vs. 166912
flight 166988 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt20 guest-start/debian.repeat fail REGR. vs. 166958
Hi Thomas,
On 11/26/2021 5:25 PM, Thomas Gleixner wrote:
Provide a new interface which allows to expand the MSI-X vector space if
the underlying irq domain implementation supports it.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 41 +
flight 166970 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 14 guest-start fail REGR. vs. 166839
On 01/12/2021 07:32, Jan Beulich wrote:
> On 30.11.2021 21:56, Andrew Cooper wrote:
>> On 29/11/2021 09:10, Jan Beulich wrote:
>>> @@ -133,14 +133,13 @@ int vpmu_do_msr(unsigned int msr, uint64
>>> goto nop;
>>>
>>> vpmu = vcpu_vpmu(curr);
>>> -ops = vpmu->arch_vpmu_ops;
>>> -
On 01/12/2021 08:31, Jan Beulich wrote:
> On 30.11.2021 22:18, Andrew Cooper wrote:
>> On 29/11/2021 09:10, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/vpmu.c
>>> +++ b/xen/arch/x86/cpu/vpmu.c
>>> @@ -480,12 +470,17 @@ static int vpmu_arch_initialise(struct v
>>> return -EINVAL;
>>>
flight 166977 xen-unstable-smoke real [real]
flight 166982 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166977/
http://logs.test-lab.xenproject.org/osstest/logs/166982/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
On 01/12/2021 09:56, Julien Grall wrote:
> Hi,
>
> On 01/12/2021 09:38, Jan Beulich wrote:
>> On 01.12.2021 10:33, Julien Grall wrote:
>>> On 30/11/2021 18:12, Ayan Kumar Halder wrote:
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -5,7 +5,7 @@
/*
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some
open-coded arithmetic in allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Use 'bitmap_copy()' to avoid an explicit 'memcpy()'
Signed-off-by: Christophe JAILLET
---
On 01/12/2021 09:14, Jan Beulich wrote:
> On 30.11.2021 19:11, Andrew Cooper wrote:
>> Most functions in this call chain have 8 parameters, meaning that the final
>> two booleans are spilled to the stack for for calls.
>>
>> First, delete nestedhap_walk_L1_p2m and introduce nhvm_hap_walk_L1_p2m()
On 01/12/2021 08:23, Jan Beulich wrote:
> On 26.11.2021 22:22, Andrew Cooper wrote:
>> Microcode loading is not a fastpath, but there are control flow security
>> benefits from using altcall()'s hardening side effect.
>>
>> Convert the existing microcode_ops pointer into a __read_mostly structure,
On 01/12/2021 08:20, Jan Beulich wrote:
> On 26.11.2021 22:22, Andrew Cooper wrote:
>> With altcall, we convert indirect branches into direct ones. With that
>> complete, none of the potential targets need an endbr64 instruction.
> Assuming that no other hooks remain which re-use the same
We will shortly release Xen 4.16.0. Some of us will be celebrating in
person in Cambridge: in the pub, next Thursday (9th December).
We'll be at the Haymakers [1], in the gazebo, from 17:00.
https://www.individualpubs.co.uk/haymakers/
https://www.openstreetmap.org/way/131306510
In addition,
flight 166969 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 14 guest-start fail REGR. vs. 166942
On 01/12/2021 10:35, Jan Beulich wrote:
> paging_mfn_is_dirty() is moderately expensive, so avoid its use unless
> its result might actually change anything. This means moving the
> surrounding if() down below all other checks that can result in clearing
> _PAGE_RW from sflags, in order to then
Hi Jan,
On 26/11/2021 08:07, Jan Beulich wrote:
On 25.11.2021 17:37, Julien Grall wrote:
On 13/09/2021 07:41, Jan Beulich wrote:
Without holding appropriate locks, attempting to remove a prior mapping
of the underlying page is pointless, as the same (or another) mapping
could be
I'm committing this now, along with the forward-ports mentioned. I
think this is mechanical release technician stuff, so I don't feel the
need for an ack.
Ian.
>From 6c1c97e24f830a921a23e3b9694e20493c9986ee Mon Sep 17 00:00:00 2001
From: Ian Jackson
To: xen-devel@lists.xenproject.org
Cc: Ian
On 01.12.21 18:22, Julien Grall wrote:
On 29/11/2021 15:58, Oleksandr wrote:
Hi Julien
Hi,
Hi Julien
[snip]
! Please note, there is still unresolved locking question here for
which
I failed to find a suitable solution. So, it is still an RFC !
According to the internal
On 01.12.21 18:32, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 26/11/2021 13:51, Oleksandr wrote:
On 25.11.21 21:04, Julien Grall wrote:
{
+ mfn_t mfn = lpae_get_mfn(pte);
+
ASSERT(p2m_is_valid(pte));
/*
@@ -731,11 +733,22 @@ static void p2m_put_l3_page(const
flight 166968 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166968/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 25 guest-start/debian fail REGR. vs. 166954
Hi Oleksandr,
On 26/11/2021 13:51, Oleksandr wrote:
On 25.11.21 21:04, Julien Grall wrote:
{
+ mfn_t mfn = lpae_get_mfn(pte);
+
ASSERT(p2m_is_valid(pte));
/*
@@ -731,11 +733,22 @@ static void p2m_put_l3_page(const lpae_t pte)
*/
if ( p2m_is_foreign(pte.p2m.type)
On 29/11/2021 15:58, Oleksandr wrote:
Hi Julien
Hi,
[snip]
! Please note, there is still unresolved locking question here for
which
I failed to find a suitable solution. So, it is still an RFC !
According to the internal conversation:
Now the GFN field in the struct page_info
Hi,
On 30/11/2021 16:14, Jan Beulich wrote:
Sufficient and in particular regular testing on very large hosts cannot
currently be guaranteed. Anyone wanting us to support larger hosts is
free to propose so, but will need to supply not only test results, but
also a test plan.
This is a follow-up
On 01/12/2021 10:35, Jan Beulich wrote:
> The function returning a boolean indicator, make it return bool. Also
> constify its struct domain parameter, albeit requiring to also adjust
> mm_locked_by_me(). Furthermore the function is used by shadow code only.
>
> Signed-off-by: Jan Beulich
>
> ---
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
mpb_desc() still needs to be handled. Use DMA API(scsi_dma_map/unmap)
to
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
pagebuffer() stills need to be handled. Use DMA API to map/umap
these memory
From: Tianyu Lan
hyperv Isolation VM requires bounce buffer support to copy
data from/to encrypted memory and so enable swiotlb force
mode to use swiotlb bounce buffer for DMA transaction.
In Isolation VM with AMD SEV, the bounce buffer needs to be
accessed via extra address space which is
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary (E.G 39 bit
address line) reported by Hyper-V CPUID ISOLATION_CONFIG. The access
physical address will be original physical address + shared_gpa_boundary.
From: Tianyu Lan
Hyper-V provides Isolation VM which has memory encrypt support. Add
hyperv_cc_platform_has() and return true for check of GUEST_MEM_ENCRYPT
attribute.
Signed-off-by: Tianyu Lan
---
arch/x86/kernel/cc_platform.c | 15 +++
1 file changed, 15 insertions(+)
diff
From: Tianyu Lan
Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
is to add support for these Isolation VM support in Linux.
The memory of these vms are encrypted and host can't access guest
memory
On 01/12/2021 11:52, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1345,19 +1345,15 @@ mark_populate_on_demand(struct domain *d
> }
> }
>
> +pod_lock(p2m);
> +p2m->pod.entry_count += (1UL << order) - pod_count;
> +
On 01/12/2021 09:39, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1457,24 +1462,24 @@ static int iommu_get_device_group(
> if ( !is_iommu_enabled(d) || !ops->get_device_group_id )
> return 0;
>
> -group_id =
On 01/12/2021 09:42, Jan Beulich wrote:
> The array of IDs is an output.
>
> Fixes: 79647c5bc9c6 ("libxc: convert domctl interfaces over to hypercall
> buffers")
> Signed-off-by: Jan Beulich
> ---
> Clearly the function, including its Python wrapper, cannot have been
> used by anything for many
flight 166966 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 22 guest-start/debian.repeat fail REGR. vs. 166912
On 01/12/2021 09:40, Jan Beulich wrote:
> The actual function should always have lived in core x86 code; move it
> there, replacing get_cache_line_size() by readily available (except very
> early during boot; see the code comment) data.
>
> Drop the respective IOMMU hook, (re)introducing a
On 01/12/2021 09:41, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -591,7 +591,8 @@ static int __must_check iommu_flush_all(
> bool_t flush_dev_iotlb;
> int rc = 0;
>
> -flush_all_cache();
> +
On 01/12/2021 10:54, Jan Beulich wrote:
> @@ -2237,11 +2243,11 @@ bool p2m_altp2m_get_or_propagate(struct
> * to the start of the superpage. NB that we repupose `amfn`
> * here.
> */
> -mask = ~((1UL << page_order) - 1);
> +mask = ~((1UL << cur_order) - 1);
> amfn =
On 01/12/2021 10:53, Jan Beulich wrote:
> Pinning is a PV concept, used there only for page table pages.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Perhaps this is a leftover from autotranslate mode? That was doing some
very HVM-like things for PV guests.
> ---
> I'm actually
On 01.12.21 10:42, Jan Beulich wrote:
The array of IDs is an output.
Fixes: 79647c5bc9c6 ("libxc: convert domctl interfaces over to hypercall
buffers")
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
On 01.12.2021 12:58, Andre Przywara wrote:
> On Tue, 30 Nov 2021 19:13:41 +
> Ayan Kumar Halder wrote:
>> On 30/11/2021 09:49, Andre Przywara wrote:
>>> On Mon, 29 Nov 2021 19:16:38 +
>>> Ayan Kumar Halder wrote:
At the moment, Xen is only handling data abort with valid syndrome
On 01/12/2021 10:53, Jan Beulich wrote:
> Avoid recurring MFN -> page or page -> MFN translations. Drop the pretty
> pointless local variable "p". Make sure the MFN logged in a debugging
> error message is actually the offending one. Adjust style.
>
> Signed-off-by: Jan Beulich
>
> ---
flight 166965 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Tue, 30 Nov 2021 19:13:41 +
Ayan Kumar Halder wrote:
Hi Ayan,
> Thanks for your comments. They are useful.
>
> On 30/11/2021 09:49, Andre Przywara wrote:
> > On Mon, 29 Nov 2021 19:16:38 +
> > Ayan Kumar Halder wrote:
> >
> > Hi,
> >
> >> At the moment, Xen is only handling
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count should indicate too large a
value in preference to a too small one, to avoid functions bailing early
when they find the count is zero. Hence increments should happen ahead
of P2M updates,
On 01.12.2021 12:27, Andrew Cooper wrote:
> On 01/12/2021 11:02, Jan Beulich wrote:
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count should indicate too large a
>> value in preference to a too small one, to avoid functions bailing
On 01.12.2021 11:32, Roger Pau Monné wrote:
> On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Beulich wrote:
>> On 01.12.2021 10:09, Roger Pau Monné wrote:
>>> On Fri, Sep 24, 2021 at 11:46:57AM +0200, Jan Beulich wrote:
@@ -267,44 +267,60 @@ static bool __hwdom_init hwdom_iommu_map
On 01/12/2021 11:02, Jan Beulich wrote:
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count should indicate too large a
> value in preference to a too small one, to avoid functions bailing early
> when they find the count is zero. Hence
On 01.12.2021 12:15, Andrew Cooper wrote:
> Andrew Cooper (2):
> xsm: Switch xsm_ops to __alt_call_maybe_initdata
> xsm: Drop extern of non-existent variable
Reviewed-by: Jan Beulich
On 01/12/2021 11:01, Jan Beulich wrote:
> Replace all comparisons against p2m_populate_on_demand (outside of
> switch() statements) with the designated predicate.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Do away with the "pod_target_out_unlock" label. In particular by folding
if()-s, the logic can be expressed with less code (and no goto-s) this
way.
Limit scope of "p2m", constifying it at the same time.
Signed-off-by: Jan Beulich
---
v2: Re-base over new earlier patch.
--- a/xen/arch/x86/mm.c
While it is okay for IOMMU page tables to get set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.
Also use the new function to
New 1st patch, subsuming the original one.
1: IOMMU/x86: disallow device assignment to PoD guests
2: x86/mm: tidy XENMEM_{get,set}_pod_target handling
Jan
Andrew Cooper (2):
xsm: Switch xsm_ops to __alt_call_maybe_initdata
xsm: Drop extern of non-existent variable
xen/include/xsm/xsm.h | 2 --
xen/xsm/xsm_core.c| 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--
2.11.0
This should have been done at the point xsm_ops became fully altcall'd. This
puts the xsm_ops structure in .init on architectures where it is no longer
referenced at runtime.
Fixes: d868feb95a8a ("xen/xsm: Complete altcall conversion of xsm interface")
Signed-off-by: Andrew Cooper
---
CC:
dummy_xsm_ops was dropped as part of organising XSM to be altcall compatible,
but the extern was accidentally left around.
A later change reintroduced dummy_ops which is logically the same thing, but
is private to xsm/dummy.c
Fixes: 164a0b9653f4 ("xsm: refactor xsm_ops handling")
Signed-off-by:
On Wed, 1 Dec 2021 08:41:13 +
Bertrand Marquis wrote:
Hi,
> > On 30 Nov 2021, at 19:13, Ayan Kumar Halder
> > wrote:
> >
> > Hi Andre,
> >
> > Thanks for your comments. They are useful.
> >
> > On 30/11/2021 09:49, Andre Przywara wrote:
> >> On Mon, 29 Nov 2021 19:16:38 +
> >> Ayan
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count should indicate too large a
value in preference to a too small one, to avoid functions bailing early
when they find the count is zero. Hence increments should happen ahead
of P2M updates,
Replace all comparisons against p2m_populate_on_demand (outside of
switch() statements) with the designated predicate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -344,7 +344,7 @@ static int ept_next_level(struct p2m_dom
{
int rc;
1: mm: don't open-code p2m_is_pod()
2: PoD: move increment of entry count
Jan
For higher order mappings the comparison against p2m->min_remapped_gfn
needs to take the upper bound of the covered GFN range into account, not
just the base GFN.
Otherwise, i.e. when dropping a mapping and not overlapping the remapped
range, XXX.
Note that there's no need to call
Prior to XSA-304 the only caller merely happened to not use any further
the order value that it passes into the function. Already then this was
a latent issue: The function really should, in the "get" case, hand back
the order the underlying mapping actually uses (or actually the smaller
of the
Pinning is a PV concept, used there only for page table pages.
Signed-off-by: Jan Beulich
---
I'm actually inclined to hide _PGT_pinned in !HVM builds; the downside
of doing so is some new #ifdef-ary which would need adding.
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@
Avoid recurring MFN -> page or page -> MFN translations. Drop the pretty
pointless local variable "p". Make sure the MFN logged in a debugging
error message is actually the offending one. Adjust style.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@
1: PoD: simplify / improve p2m_pod_cache_add()
2: PoD: HVM guests can't pin their pages
3: altp2m: p2m_altp2m_get_or_propagate() should honor present page order
4: altp2m: p2m_altp2m_propagate_change() should honor present page order
The last one is RFC, as there is an aspect I can't make sense
Cedric,
On Wed, Dec 01 2021 at 08:14, Cédric Le Goater wrote:
> On 11/30/21 23:41, Thomas Gleixner wrote:
>> It's not the core function. It's the patch above and I'm a moron.
>
> All good now. Ship it !
thanks a lot for testing this and dealing with the fallout. Much
appreciated!
tglx
The function returning a boolean indicator, make it return bool. Also
constify its struct domain parameter, albeit requiring to also adjust
mm_locked_by_me(). Furthermore the function is used by shadow code only.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mm-locks.h
+++
paging_mfn_is_dirty() is moderately expensive, so avoid its use unless
its result might actually change anything. This means moving the
surrounding if() down below all other checks that can result in clearing
_PAGE_RW from sflags, in order to then check whether _PAGE_RW is
actually still set there
1: shadow: defer/avoid paging_mfn_is_dirty() invocation
2: paging: tidy paging_mfn_is_dirty()
Jan
On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Beulich wrote:
> On 01.12.2021 10:09, Roger Pau Monné wrote:
> > On Fri, Sep 24, 2021 at 11:46:57AM +0200, Jan Beulich wrote:
> >> @@ -267,44 +267,60 @@ static bool __hwdom_init hwdom_iommu_map
> >> * that fall in unusable ranges for PV Dom0.
>
On 01/12/2021 08:10, Jan Beulich wrote:
> On 26.11.2021 22:22, Andrew Cooper wrote:
>> @@ -279,6 +280,27 @@ static void init_or_livepatch
>> _apply_alternatives(struct alt_instr *start,
>>
>> if ( dest )
>> {
>> +/*
>> +
flight 166971 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166971/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen e7f147bf4ac725492962a501da72f5ab6be682db
baseline version:
xen
Hi,
On 01/12/2021 09:38, Jan Beulich wrote:
On 01.12.2021 10:33, Julien Grall wrote:
On 30/11/2021 18:12, Ayan Kumar Halder wrote:
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -5,7 +5,7 @@
/*
* Create a contiguous bitmask starting at bit position @l and ending at
The array of IDs is an output.
Fixes: 79647c5bc9c6 ("libxc: convert domctl interfaces over to hypercall
buffers")
Signed-off-by: Jan Beulich
---
Clearly the function, including its Python wrapper, cannot have been
used by anything for many years. I wonder whether that isn't good enough
a reason
The actual function should always have lived in core x86 code; move it
there, replacing get_cache_line_size() by readily available (except very
early during boot; see the code comment) data.
Drop the respective IOMMU hook, (re)introducing a respective boolean
instead. Replace a true and an almost
Let's use infrastructure we have available instead of an open-coded
wbinvd() invocation.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -76,8 +76,6 @@ int __must_check qinval_device_iotlb_syn
This is, once again, to limit the number of indirect calls as much as
possible. The only hook invocation which isn't sensible to convert is
setup(). And of course Arm-only use sites are left alone as well.
Note regarding the introduction / use of local variables in pci.c:
struct pci_dev's
On 01.12.2021 10:33, Julien Grall wrote:
> On 30/11/2021 18:12, Ayan Kumar Halder wrote:
>> --- a/xen/include/xen/bitops.h
>> +++ b/xen/include/xen/bitops.h
>> @@ -5,7 +5,7 @@
>> /*
>>* Create a contiguous bitmask starting at bit position @l and ending at
>>* position @h. For example
>>
Besides the altcall conversion, some further adjustments appeared desirable
to do while touching that area.
1: IOMMU/x86: switch to alternatives-call patching in further instances
2: VT-d / x86: re-arrange cache syncing
3: VT-d: replace flush_all_cache()
4: libxc: correct bounce direction in
Hi,
On 30/11/2021 18:12, Ayan Kumar Halder wrote:
GENMASK(30, 21) should be 0x7fe0. Fixed this in the comment
in bitops.h.
I am afraid this commit message is incomplete. You say you just
corrected the bitmask returned but...
Signed-off-by: Ayan Kumar Halder
---
Changelog :-
v2 :- 1.
On 01.12.2021 10:09, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:46:57AM +0200, Jan Beulich wrote:
>> @@ -267,44 +267,60 @@ static bool __hwdom_init hwdom_iommu_map
>> * that fall in unusable ranges for PV Dom0.
>> */
>> if ( (pfn > max_pfn && !mfn_valid(mfn)) ||
On 30.11.2021 19:11, Andrew Cooper wrote:
> Most functions in this call chain have 8 parameters, meaning that the final
> two booleans are spilled to the stack for for calls.
>
> First, delete nestedhap_walk_L1_p2m and introduce nhvm_hap_walk_L1_p2m() as a
> thin wrapper around hvm_funcs just
On Fri, Sep 24, 2021 at 11:46:57AM +0200, Jan Beulich wrote:
> While already the case for PVH, there's no reason to treat PV
> differently here, though of course the addresses get taken from another
> source in this case. Except that, to match CPU side mappings, by default
> we permit r/o ones.
On 30.11.2021 19:11, Andrew Cooper wrote:
> The sole caller doesn't check the return value, and both vendors implement the
> hook.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Hi Ayan,
> On 30 Nov 2021, at 19:13, Ayan Kumar Halder
> wrote:
>
> Hi Andre,
>
> Thanks for your comments. They are useful.
>
> On 30/11/2021 09:49, Andre Przywara wrote:
>> On Mon, 29 Nov 2021 19:16:38 +
>> Ayan Kumar Halder wrote:
>> Hi,
>>> At the moment, Xen is only handling data
Hi Ayan,
> On 30 Nov 2021, at 18:12, Ayan Kumar Halder
> wrote:
>
> GENMASK(30, 21) should be 0x7fe0. Fixed this in the comment
> in bitops.h.
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Changelog :-
> v2 :- 1. Replaced the word "vector"
On 30.11.2021 22:18, Andrew Cooper wrote:
> On 29/11/2021 09:10, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -480,12 +470,17 @@ static int vpmu_arch_initialise(struct v
>> return -EINVAL;
>> }
>>
>> -vpmu->hw_lapic_lvtpc =
flight 166963 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 22 guest-start/debian.repeat fail REGR. vs.
166942
On 26.11.2021 22:22, Andrew Cooper wrote:
> Microcode loading is not a fastpath, but there are control flow security
> benefits from using altcall()'s hardening side effect.
>
> Convert the existing microcode_ops pointer into a __read_mostly structure, and
> move {amd,intel}_ucode_ops into
On 26.11.2021 22:22, Andrew Cooper wrote:
> All calls through xsm_ops are fully altcall'd. Harden all fnptr targets.
>
> This yields:
>
> (XEN) altcall: Optimised away 197 endbr64 instructions
>
> of 1655 on an everything-enabled build of Xen, which is ~12%.
>
> Signed-off-by: Andrew Cooper
On 26.11.2021 22:22, Andrew Cooper wrote:
> With altcall, we convert indirect branches into direct ones. With that
> complete, none of the potential targets need an endbr64 instruction.
Assuming that no other hooks remain which re-use the same function. I
think this constraint wants at least
On 26.11.2021 22:22, Andrew Cooper wrote:
> @@ -279,6 +280,27 @@ static void init_or_livepatch _apply_alternatives(struct
> alt_instr *start,
>
> if ( dest )
> {
> +/*
> + * When building for CET-IBT, all function pointer
On 30.11.2021 23:05, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -518,7 +518,7 @@ static int svm_vpmu_initialise(struct vcpu *v)
> return 0;
> }
>
> -static const struct arch_vpmu_ops __initconstrel amd_vpmu_ops = {
> +static struct
96 matches
Mail list logo
