flight 161322 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161322/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161049
flight 161320 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On Tue, 20 Apr 2021, Julien Grall wrote:
> (+ Andrew and Jan)
>
> Hi Stefano,
>
> On 20/04/2021 20:38, Stefano Stabellini wrote:
> > On Fri, 16 Apr 2021, Julien Grall wrote:
> > > > I think your explanation is correct. However, don't we need a smp_rmb()
> > > > barrier after reading
flight 161338 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161338/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 161317 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161317/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 161296
Tests which did not
Thanks again Andrew, ...
My initial idea was to allocate a frame on kernel space and change the
update_va_mapping to "forcibly" write the desired MFN as the l1 page table
and return the va.
You can see what I did here:
(+ Andrew and Jan)
Hi Stefano,
On 20/04/2021 20:38, Stefano Stabellini wrote:
On Fri, 16 Apr 2021, Julien Grall wrote:
I think your explanation is correct. However, don't we need a smp_rmb()
barrier after reading v->is_initialised in xen/common/domctl.c:do_domctl
? That would be the barrier
On Fri, 16 Apr 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 13/04/2021 23:43, Stefano Stabellini wrote:
> > On Sat, 20 Mar 2021, Julien Grall wrote:
> > > On 20/03/2021 00:01, Stefano Stabellini wrote:
> > > > On Sat, 27 Feb 2021, Julien Grall wrote:
> > > > > (+ Dario and George)
> > > > >
>
On 20/04/2021 17:13, Charles Gonçalves wrote:
> Hello Guys,
>
> I'm trying to reproduce old exploit behaviors in a simplistic way:
> create an hypercall to write a buffer to a specific MFN.
>
> At first, I thought that updating an l1 page in a valid VA in guest
> kernel space would do the trick.
Factor out a compat boolean to remove the lfence overhead from multiple
is_pv_32bit_domain() calls.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* Reinstate the conditional for the start info pointer, in case Intel/AMD
can't be persuaded to adjust
On 19/04/2021 17:00, Jan Beulich wrote:
> On 19.04.2021 17:57, Andrew Cooper wrote:
>> On 19/04/2021 16:55, Jan Beulich wrote:
>>> On 19.04.2021 16:45, Andrew Cooper wrote:
Factor out a compat boolean to remove the lfence overhead from multiple
is_pv_32bit_domain() calls.
For a
flight 161332 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161332/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 161308 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote:
> On 20.04.2021 17:29, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote:
> >> @@ -399,7 +399,11 @@ include/xen/compile.h: include/xen/compi
> >>@sed -rf tools/process-banner.sed < .banner >>
On Tue, Apr 20, 2021 at 05:38:51PM +0200, Jan Beulich wrote:
> On 20.04.2021 17:08, Roger Pau Monné wrote:
> > On Thu, Apr 02, 2020 at 04:06:06AM +0800, Chao Gao wrote:
> >> --- a/xen/drivers/passthrough/vtd/qinval.c
> >> +++ b/xen/drivers/passthrough/vtd/qinval.c
> >> @@ -442,6 +442,23 @@ int
Hello Guys,
I'm trying to reproduce old exploit behaviors in a simplistic way: create
an hypercall to write a buffer to a specific MFN.
At first, I thought that updating an l1 page in a valid VA in guest kernel
space would do the trick.
But for addresses outside the Guest-defined use
On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote:
> Reading the platform timer isn't cheap, so we'd better avoid it when the
> resulting value is of no interest to anyone.
>
> The consumer of master_stime, obtained by
> time_calibration_{std,tsc}_rendezvous() and propagated through
>
On Thu, Apr 01, 2021 at 11:54:27AM +0200, Jan Beulich wrote:
> Since we'd like the updates to be done as synchronously as possible,
> make an attempt at yielding immediately after the TSC write.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Did you observe any difference with
On 20.04.2021 17:29, Roger Pau Monné wrote:
> On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote:
>> @@ -399,7 +399,11 @@ include/xen/compile.h: include/xen/compi
>> @sed -rf tools/process-banner.sed < .banner >> $@.new
>> @mv -f $@.new $@
>>
>>
On Thu, Apr 01, 2021 at 11:54:05AM +0200, Jan Beulich wrote:
> To reduce latency on time_calibration_tsc_rendezvous()'s last loop
> iteration, read the value to be written on the last iteration at the end
> of the loop body (i.e. in particular at the end of the second to last
> iteration).
>
> On
On 20.04.2021 17:08, Roger Pau Monné wrote:
> On Thu, Apr 02, 2020 at 04:06:06AM +0800, Chao Gao wrote:
>> --- a/xen/drivers/passthrough/vtd/qinval.c
>> +++ b/xen/drivers/passthrough/vtd/qinval.c
>> @@ -442,6 +442,23 @@ int enable_qinval(struct vtd_iommu *iommu)
>> return 0;
>> }
>>
>>
On 20.04.2021 15:45, Rahul Singh wrote:
>> On 19 Apr 2021, at 1:33 pm, Jan Beulich wrote:
>> On 19.04.2021 13:54, Julien Grall wrote:
>>> For the time being, I think move this code in x86 is a lot better than
>>> #ifdef or keep the code in common code.
>>
>> Well, I would perhaps agree if it
On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote:
> Except for an additional prereq Arm and x86 have the same needs here,
> and Arm can also benefit from the recent x86 side improvement. Recurse
> into arch/*/ only for a phony include target (doing nothing on Arm),
> and handle
Hi Julien,
On 20 Apr 2021, at 14:49, Julien Grall mailto:jul...@xen.org>>
wrote:
From: Julien Grall mailto:jgr...@amazon.com>>
A prototype for dump_conn() has been present for quite a long time
but there are no implementation. Even, AFAICT in the patch that
introduced it. So drop it.
On Thu, Apr 02, 2020 at 04:06:06AM +0800, Chao Gao wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -442,6 +442,23 @@ int enable_qinval(struct vtd_iommu *iommu)
> return 0;
> }
>
> +static int vtd_flush_context_noop(struct vtd_iommu
flight 161321 xen-unstable-smoke real [real]
flight 161328 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161321/
http://logs.test-lab.xenproject.org/osstest/logs/161328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
There's no caller anymore that cares about the injected vector, so
drop the returned vector from the function.
No functional change indented.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this version.
---
xen/arch/x86/hvm/irq.c| 8 ++--
Introduce a per virtual timer lock that replaces the existing per-vCPU
and per-domain vPT locks. Since virtual timers are no longer assigned
or migrated between vCPUs the locking can be simplified to a
in-structure spinlock that protects all the fields.
This requires introducing a helper to
There are no callers anymore passing a get_vector function pointer to
hvm_isa_irq_assert, so drop the parameter.
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this version.
---
xen/arch/x86/hvm/dm.c | 2 +-
xen/arch/x86/hvm/irq.c
Currently vPT relies on timers being assigned to a vCPU and performing
checks on every return to HVM guest in order to check if an interrupt
from a vPT timer assigned to the vCPU is currently being injected.
This model doesn't work properly since the interrupt destination vCPU
of a vPT timer can
No longer add vPT timers to lists on specific vCPUs, since there's no
need anymore to check if timer interrupts have been injected on return
to HVM guest.
Such change allows to get rid of virtual timers vCPU migration, and
also cleanup some of the virtual timers fields that are no longer
Switch the dpci GSI EOI callback hooks to use the newly introduced
generic callback functionality, and remove the custom dpci calls found
on the vPIC and vIO-APIC implementations.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Print a warning message if the EOI callback cannot be
This is code movement in order to simply further changes.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v2:
- Drop one of the leading underscores from __hvm_dpci_eoi.
Changes since v1:
- New in this version.
---
Such callbacks will be executed once a EOI is performed by the guest,
regardless of whether the interrupts are injected from the vIO-APIC or
the vPIC, as ISA IRQs are translated to GSIs and then the
corresponding callback is executed at EOI.
The vIO-APIC infrastructure for handling EOIs is build
Switch the emulated IO-APIC code to use the local APIC EOI callback
mechanism. This allows to remove the last hardcoded callback from
vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also
allows to getting rid of setting the EOI exit bitmap based on the
triggering mode, as now all users
Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
and instead use the newly introduced EOI callback mechanism in order
to register a callback for MSI vectors injected from passed through
devices.
This avoids having multiple callback functions open-coded in
vlapic_handle_EOI,
Add a new vlapic_set_irq_callback helper in order to inject a vector
and set a callback to be executed when the guest performs the end of
interrupt acknowledgment.
Such functionality will be used to migrate the current ad hoc handling
done in vlapic_handle_EOI for the vectors that require some
Xen has been for a long time setting the WAET ACPI table "RTC good"
flag, which implies there's no need to perform a read of the RTC REG_C
register in order to get further interrupts after having received one.
This is hardcoded in the static ACPI tables, and in the RTC emulation
in Xen.
Drop the
Hello,
The following series introduces EOI callbacks and switches a number of
subsystems to use them. The first one is vmsi and dpci, which are quite
straight forward to switch since they used to open code hooks in the EOI
handlers.
Finally HVM virtual timers are also switched to a different
flight 161304 xen-4.12-testing real [real]
flight 161327 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161304/
http://logs.test-lab.xenproject.org/osstest/logs/161327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi Julien,
> On 20 Apr 2021, at 1:39 pm, Julien Grall wrote:
>
> Hi,
>
> On 19/04/2021 17:21, Stefano Stabellini wrote:
>> On Mon, 19 Apr 2021, Rahul Singh wrote:
>>> Hi Julien,
>>>
On 18 Apr 2021, at 6:48 pm, Julien Grall wrote:
On 16/04/2021 17:41, Rahul Singh
From: Julien Grall
A prototype for dump_conn() has been present for quite a long time
but there are no implementation. Even, AFAICT in the patch that
introduced it. So drop it.
Signed-off-by: Julien Grall
---
tools/xenstore/xenstored_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On 4/20/21 4:23 AM, Christoph Hellwig wrote:
> On Sat, Apr 17, 2021 at 11:39:22AM -0500, Tom Lendacky wrote:
>> Somewhere between the 1st and 2nd patch, specifying a specific swiotlb
>> for an SEV guest is no longer honored. For example, if I start an SEV
>> guest with 16GB of memory and specify
Hi Jan
> On 19 Apr 2021, at 1:33 pm, Jan Beulich wrote:
>
> On 19.04.2021 13:54, Julien Grall wrote:
>> For the time being, I think move this code in x86 is a lot better than
>> #ifdef or keep the code in common code.
>
> Well, I would perhaps agree if it ended up being #ifdef CONFIG_X86.
> I
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
Hi Michal,
On 20/04/2021 08:08, Michal Orzel wrote:
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when
On 20/04/2021 13:50, Jan Beulich wrote:
Alternatively, you could be a bit more
verbose in your request so the other understand the reasoning behind it.
Well, yes, perhaps. But then there's the desire to not repeat oneself
all the time.
Most likely, the time you try to save not expanding
On 20.04.2021 14:39, Julien Grall wrote:
> On 20/04/2021 13:25, Jan Beulich wrote:
>> On 20.04.2021 14:14, Julien Grall wrote:
>>> It is not really my area of expertise but I wanted to jump on one
>>> comment below...
>>>
>>> On 20/04/2021 12:38, Jan Beulich wrote:
On 01.04.2020 22:06, Chao
On 15/04/2021 15:47, Roger Pau Monne wrote:
> AMD Milan (Zen3) CPUs have an LFENCE Always Serializing CPUID bit in
> leaf 8021.eax. Previous AMD versions used to have a user settable
> bit in DE_CFG MSR to select whether LFENCE was dispatch serializing,
> which Xen always attempts to set. The
Hi,
On 19/04/2021 17:21, Stefano Stabellini wrote:
On Mon, 19 Apr 2021, Rahul Singh wrote:
Hi Julien,
On 18 Apr 2021, at 6:48 pm, Julien Grall wrote:
On 16/04/2021 17:41, Rahul Singh wrote:
Hi Julien
Hi Rahul,
On 16 Apr 2021, at 5:08 pm, Julien Grall wrote:
On 16/04/2021 17:05,
Hi,
On 20/04/2021 13:25, Jan Beulich wrote:
On 20.04.2021 14:14, Julien Grall wrote:
Hi,
It is not really my area of expertise but I wanted to jump on one
comment below...
On 20/04/2021 12:38, Jan Beulich wrote:
On 01.04.2020 22:06, Chao Gao wrote:
---
Changes in v2:
- verify system
On Tue, Apr 20, 2021 at 01:38:26PM +0200, Jan Beulich wrote:
>On 01.04.2020 22:06, Chao Gao wrote:
>> According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
>> isn't supported by Intel VT-d version 6 and beyond.
>>
>> This hardware change impacts following two scenarios:
flight 161312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161312/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0bbc20727598421c4e47d46b982246217df8c6bc
baseline version:
ovmf
On 06.04.2021 13:05, Hongyan Xia wrote:
> @@ -742,51 +742,58 @@ static int clone_mapping(const void *ptr,
> root_pgentry_t *rpt)
> }
> }
>
> +UNMAP_DOMAIN_PAGE(pl1e);
> +UNMAP_DOMAIN_PAGE(pl2e);
> +UNMAP_DOMAIN_PAGE(pl3e);
Just one minor remark: A pedantic(?) compiler
On 06.04.2021 13:05, Hongyan Xia wrote:
> From: Wei Liu
>
> We will soon need to clean up page table mappings in the exit path.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Acked-by: Jan Beulich
On 20.04.2021 14:14, Julien Grall wrote:
> Hi,
>
> It is not really my area of expertise but I wanted to jump on one
> comment below...
>
> On 20/04/2021 12:38, Jan Beulich wrote:
>> On 01.04.2020 22:06, Chao Gao wrote:
>>> ---
>>> Changes in v2:
>>> - verify system suspension and resumption
On 06.04.2021 13:05, Hongyan Xia wrote:
> From: Wei Liu
>
> Rewrite those functions to use the new APIs. Modify its callers to unmap
> the pointer returned. Since alloc_xen_pagetable_new() is almost never
> useful unless accompanied by page clearing and a mapping, introduce a
> helper
Hi,
On 19/04/2021 19:24, Stefano Stabellini wrote:
On Mon, 19 Apr 2021, Bertrand Marquis wrote:
Hi Julien,
On 18 Apr 2021, at 19:03, Julien Grall wrote:
From: Julien Grall
Some CPUs can speculate past a RET instruction and potentially perform
speculative accesses to memory before
Hi,
It is not really my area of expertise but I wanted to jump on one
comment below...
On 20/04/2021 12:38, Jan Beulich wrote:
On 01.04.2020 22:06, Chao Gao wrote:
---
Changes in v2:
- verify system suspension and resumption with this patch applied
- don't fall back to register-based
On 01.04.2020 22:06, Chao Gao wrote:
> According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
> isn't supported by Intel VT-d version 6 and beyond.
>
> This hardware change impacts following two scenarios: admin can disable
> queued invalidation via 'qinval' cmdline and use
On 20.04.2021 12:47, Roger Pau Monné wrote:
> On Tue, Apr 20, 2021 at 12:35:54PM +0200, Jan Beulich wrote:
>> I'd like to give Andrew a day or two more to respond there in case he
>> continues to see an issue, before I commit that with your R-b and this
>> one here. I'll assume you'll subsequently
According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
isn't supported by Intel VT-d version 6 and beyond.
This hardware change impacts following two scenarios: admin can disable
queued invalidation via 'qinval' cmdline and use register-based interface;
VT-d switches to
On Tue, Apr 20, 2021 at 10:51:47AM +0100, Igor Druzhinin wrote:
> On 20/04/2021 04:39, no-re...@patchew.org wrote:
> > === OUTPUT BEGIN ===
> > ERROR: Author email address is mangled by the mailing list
> > #2:
> > Author: Igor Druzhinin via
> >
> > total: 1 errors, 0 warnings, 21 lines checked
On Tue, Apr 20, 2021 at 12:35:54PM +0200, Jan Beulich wrote:
> On 15.04.2021 16:47, Roger Pau Monne wrote:
> > AMD Milan (Zen3) CPUs have an LFENCE Always Serializing CPUID bit in
> > leaf 8021.eax. Previous AMD versions used to have a user settable
> > bit in DE_CFG MSR to select whether
On 15.04.2021 16:47, Roger Pau Monne wrote:
> AMD Milan (Zen3) CPUs have an LFENCE Always Serializing CPUID bit in
> leaf 8021.eax. Previous AMD versions used to have a user settable
> bit in DE_CFG MSR to select whether LFENCE was dispatch serializing,
> which Xen always attempts to set. The
On 20.04.2021 11:42, Luca Fancellu wrote:
>> On 20 Apr 2021, at 10:14, Jan Beulich wrote:
>> On 20.04.2021 10:46, Luca Fancellu wrote:
On 19 Apr 2021, at 12:05, Jan Beulich wrote:
On 19.04.2021 11:12, Luca Fancellu wrote:
> - */
> -
> -/*
> - * Reference to a grant
On Tue, Apr 20, 2021 at 10:45:03AM +0100, Igor Druzhinin wrote:
> On 20/04/2021 09:53, Roger Pau Monné wrote:
> > On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
> > > When we're replacing the existing mapping there is possibility of a race
> > > on memory map with other threads
flight 161298 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On 20/04/2021 04:39, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/1618889702-13104-1-git-send-email-igor.druzhi...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id:
On 20/04/2021 09:53, Roger Pau Monné wrote:
On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
When we're replacing the existing mapping there is possibility of a race
on memory map with other threads doing mmap operations - the address being
unmapped/re-mapped could be occupied by
> On 20 Apr 2021, at 10:14, Jan Beulich wrote:
>
> On 20.04.2021 10:46, Luca Fancellu wrote:
>>> On 19 Apr 2021, at 12:05, Jan Beulich wrote:
>>>
>>> On 19.04.2021 11:12, Luca Fancellu wrote:
Modification to include/public/grant_table.h:
1) Add doxygen tags to:
- Create
On 26.01.2021 17:57, Jan Beulich wrote:
> On 26.01.2021 14:45, Roger Pau Monne wrote:
>> When pins are cleared from either ISR or IRR as part of the
>> initialization sequence forward the clearing of those pins to the dpci
>> EOI handler, as it is equivalent to an EOI. Not doing so can bring the
branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware
On Sat, Apr 17, 2021 at 11:39:22AM -0500, Tom Lendacky wrote:
> Somewhere between the 1st and 2nd patch, specifying a specific swiotlb
> for an SEV guest is no longer honored. For example, if I start an SEV
> guest with 16GB of memory and specify swiotlb=131072 I used to get a
> 256MB SWIOTLB.
flight 161311 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161311/
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 20.04.2021 10:46, Luca Fancellu wrote:
>> On 19 Apr 2021, at 12:05, Jan Beulich wrote:
>>
>> On 19.04.2021 11:12, Luca Fancellu wrote:
>>> Modification to include/public/grant_table.h:
>>>
>>> 1) Add doxygen tags to:
>>> - Create Grant tables section
>>> - include variables in the generated
On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
> When we're replacing the existing mapping there is possibility of a race
> on memory map with other threads doing mmap operations - the address being
> unmapped/re-mapped could be occupied by another thread in between.
>
> Linux
> On 19 Apr 2021, at 12:05, Jan Beulich wrote:
>
> On 19.04.2021 11:12, Luca Fancellu wrote:
>> Modification to include/public/grant_table.h:
>>
>> 1) Add doxygen tags to:
>> - Create Grant tables section
>> - include variables in the generated documentation
>> 2) Add .rst file for grant
On Mon, Apr 19, 2021 at 02:29:38PM +0200, Jan Beulich wrote:
> On 19.04.2021 14:09, Roger Pau Monné wrote:
> > On Mon, Apr 19, 2021 at 01:46:02PM +0200, Jan Beulich wrote:
> >> On 19.04.2021 11:16, Roger Pau Monné wrote:
> >>> Adding Paul also for the Viridian part.
> >>>
> >>> On Fri, Apr 16,
flight 161296 xen-unstable real [real]
flight 161315 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161296/
http://logs.test-lab.xenproject.org/osstest/logs/161315/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
The purpose of this patch series is to remove 32bit helper
macros READ/WRITE_SYSREG32 on arm64 as the idea of them is
not following the latest ARMv8 specification and mrs/msr instructions
are expecting 64bit values.
According to ARM DDI 0487G.a all the AArch64 system registers
are 64bit wide even
AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or
On 20/04/2021 04:35, Igor Druzhinin wrote:
When we're replacing the existing mapping there is possibility of a race
on memory map with other threads doing mmap operations - the address being
unmapped/re-mapped could be occupied by another thread in between.
Linux mmap man page recommends
94 matches
Mail list logo
