Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to gem objects and pass it to
drm_prime_pages_to_sg() calls in drivers and helpers.
Signed-off-by: Gerd Hoffm
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to gem objects and pass it to
drm_prime_pages_to_sg() calls in d
On 18.08.2020 00:56, Stefano Stabellini wrote:
> On Mon, 17 Aug 2020, Jan Beulich wrote:
>> On 07.08.2020 23:50, Stefano Stabellini wrote:
>>> On Fri, 7 Aug 2020, Jan Beulich wrote:
On 07.08.2020 01:49, Stefano Stabellini wrote:
> On Thu, 6 Aug 2020, Julien Grall wrote:
>> On 06/08/202
On 18.08.2020 00:56, Stefano Stabellini wrote:
> On Mon, 17 Aug 2020, Jan Beulich wrote:
>> On 07.08.2020 23:51, Stefano Stabellini wrote:
>>> On Fri, 7 Aug 2020, Jan Beulich wrote:
On 07.08.2020 01:49, Stefano Stabellini wrote:
> @@ -200,90 +236,115 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys
On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote:
> Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
> > Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
> > through to the __sg_alloc_table_from_pages() call, otherwise use
> > SCATTERLIST_MAX_SEGMENT.
> >
> > Also a
On 12.08.2020 15:13, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 August 2020 13:34
>>
>> On 04.08.2020 15:42, Paul Durrant wrote:
>>> --- a/xen/drivers/passthrough/vtd/iommu.h
>>> +++ b/xen/drivers/passthrough/vtd/iommu.h
>>> @@ -184,21 +184,28 @@
>>> #defi
Am 18.08.20 um 10:27 schrieb Gerd Hoffmann:
On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote:
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTE
On 14.08.2020 21:25, Julien Grall wrote:
> Hi Andrew,
>
> Sorry for the late answer.
>
> On 23/07/2020 14:59, Andrew Cooper wrote:
>> On 23/07/2020 14:22, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 23/07/2020 12:23, Jan Beulich wrote:
On 22.07.2020 18:53, Julien Grall wrote:
> --- a/xen/
On 13.08.2020 19:22, Julien Grall wrote:
> Hi,
>
> On 13/08/2020 17:08, Hongyan Xia wrote:
>> On Fri, 2020-08-07 at 16:05 +0200, Jan Beulich wrote:
>>> On 27.07.2020 16:21, Hongyan Xia wrote:
From: Wei Liu
Rewrite those functions to use the new APIs. Modify its callers to
unma
> On 18 Aug 2020, at 04:11, Wei Chen wrote:
>
> Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
> FP/SIMD or not. But currently, this two MACROs only consider value 0
> of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
> that support FP/SIMD and half-preci
On 14.08.2020 21:07, Julien Grall wrote:
> Hi Jan,
>
> On 31/07/2020 12:36, Jan Beulich wrote:
>> On 30.07.2020 20:18, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Only a few places are actually including asm/guest_access.h. While this
>>> is fine today, a follow-up patch will want to move
On 14.08.2020 21:18, Julien Grall wrote:
> On 31/07/2020 12:41, Jan Beulich wrote:
>> On 30.07.2020 20:18, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> * Add space before and after operator
>>> * Align \
>>> * Format comments
>>
>> How about also
>>
>> * remove/replace le
Hi Jan,
On 18/08/2020 09:39, Jan Beulich wrote:
On 14.08.2020 21:25, Julien Grall wrote:
Hi Andrew,
Sorry for the late answer.
On 23/07/2020 14:59, Andrew Cooper wrote:
On 23/07/2020 14:22, Julien Grall wrote:
Hi Jan,
On 23/07/2020 12:23, Jan Beulich wrote:
On 22.07.2020 18:53, Julien Gra
On 18.08.2020 10:53, Julien Grall wrote:
> Hi Jan,
>
> On 18/08/2020 09:39, Jan Beulich wrote:
>> On 14.08.2020 21:25, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> Sorry for the late answer.
>>>
>>> On 23/07/2020 14:59, Andrew Cooper wrote:
On 23/07/2020 14:22, Julien Grall wrote:
> Hi Jan,
On 18/08/2020 09:50, Jan Beulich wrote:
On 14.08.2020 21:07, Julien Grall wrote:
Hi Jan,
On 31/07/2020 12:36, Jan Beulich wrote:
On 30.07.2020 20:18, Julien Grall wrote:
From: Julien Grall
Only a few places are actually including asm/guest_access.h. While this
is fine today, a follow-up
Hi,
> > > I'm missing an explanation why this should be useful (it certainly is).
> > virtio-gpu needs this to work properly with SEV (see patch 2/2 of this
> > series).
>
> Yeah, that's the problem patch 2/2 never showed up here :)
The list should have everything.
Your inbox probably has 1/2
Hi Jan,
On 18/08/2020 09:52, Jan Beulich wrote:
On 14.08.2020 21:18, Julien Grall wrote:
On 31/07/2020 12:41, Jan Beulich wrote:
On 30.07.2020 20:18, Julien Grall wrote:
From: Julien Grall
* Add space before and after operator
* Align \
* Format comments
How about also
> On 18 Aug 2020, at 09:58, Julien Grall wrote:
>
>
>
> On 18/08/2020 09:50, Jan Beulich wrote:
>> On 14.08.2020 21:07, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 31/07/2020 12:36, Jan Beulich wrote:
On 30.07.2020 20:18, Julien Grall wrote:
> From: Julien Grall
>
> Only a
Hi Jan,
On 18/08/2020 09:57, Jan Beulich wrote:
On 18.08.2020 10:53, Julien Grall wrote:
Hi Jan,
On 18/08/2020 09:39, Jan Beulich wrote:
On 14.08.2020 21:25, Julien Grall wrote:
Hi Andrew,
Sorry for the late answer.
On 23/07/2020 14:59, Andrew Cooper wrote:
On 23/07/2020 14:22, Julien Gra
On 18/08/2020 04:11, Wei Chen wrote:
Hi Wei,
> Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
> FP/SIMD or not. But currently, this two MACROs only consider value 0
> of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
> that support FP/SIMD and half-precision
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to drm driver and pass it to
drm_prime_pages_to_sg() calls in drivers and helpers.
v2: place max_segment in d
On 18/08/2020 10:05, Bertrand Marquis wrote:
On 18 Aug 2020, at 09:58, Julien Grall wrote:
On 18/08/2020 09:50, Jan Beulich wrote:
On 14.08.2020 21:07, Julien Grall wrote:
Hi Jan,
On 31/07/2020 12:36, Jan Beulich wrote:
On 30.07.2020 20:18, Julien Grall wrote:
From: Julien Grall
> On 18 Aug 2020, at 10:14, André Przywara wrote:
>
> On 18/08/2020 04:11, Wei Chen wrote:
>
> Hi Wei,
>
>> Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
>> FP/SIMD or not. But currently, this two MACROs only consider value 0
>> of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD featu
> On 18 Aug 2020, at 10:23, Julien Grall wrote:
>
>
>
> On 18/08/2020 10:05, Bertrand Marquis wrote:
>>> On 18 Aug 2020, at 09:58, Julien Grall wrote:
>>>
>>>
>>>
>>> On 18/08/2020 09:50, Jan Beulich wrote:
On 14.08.2020 21:07, Julien Grall wrote:
> Hi Jan,
>
> On 31/07/
Hi Stefano,
On 11/08/2020 23:48, Stefano Stabellini wrote:
On Tue, 11 Aug 2020, Julien Grall wrote:
I vaguely
recall a bug 10+ years ago about this with QEMU on x86 and a line that
could be both active-high and active-low. So QEMU would raise the
interrupt but Xen would actually think that QE
Since commit 6b85e427098cce1a6d386b3bae2f0c7ce86e47f7 'xen-cpuid -p' shows the
cpuid policies. I think these policies define what a domU will get to see when
cpuid() is invoked, or when MSRs are accessed.
Unfortunately this commit shows only the raw hex values, which makes it
difficult to compa
On 18/08/2020 10:25, Bertrand Marquis wrote:
Hi,
>> On 18 Aug 2020, at 10:14, André Przywara wrote:
>>
>> On 18/08/2020 04:11, Wei Chen wrote:
>>
>> Hi Wei,
>>
>>> Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
>>> FP/SIMD or not. But currently, this two MACROs only consider
Hi Bertrand,
On 18/08/2020 10:25, Bertrand Marquis wrote:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 674beb0353..588089e5ae 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -13,8 +13,8 @@
#define cpu_has_el2_64
Hi Wei,
On 18/08/2020 04:11, Wei Chen wrote:
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
FP/SIMD or not. But currently, this two MACROs only consider value 0
s/this/these/
of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
that support FP/SIMD and hal
Hi Jan,
On 18/08/2020 09:49, Jan Beulich wrote:
On 13.08.2020 19:22, Julien Grall wrote:
Hi,
On 13/08/2020 17:08, Hongyan Xia wrote:
On Fri, 2020-08-07 at 16:05 +0200, Jan Beulich wrote:
On 27.07.2020 16:21, Hongyan Xia wrote:
From: Wei Liu
Rewrite those functions to use the new APIs. Mod
> On 18 Aug 2020, at 10:42, André Przywara wrote:
>
> On 18/08/2020 10:25, Bertrand Marquis wrote:
>
> Hi,
>
>>> On 18 Aug 2020, at 10:14, André Przywara wrote:
>>>
>>> On 18/08/2020 04:11, Wei Chen wrote:
>>>
>>> Hi Wei,
>>>
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU
From: Paul Durrant
The first 3 patches of the series are largely the same as v6 but patches
4 thru 9 are basically new (patch 7 being inherited from v6 but heavily
re-worked).
Patch 4 is cleanup work that I noticed needed doing whilst working patch 5.
Paul Durrant (9):
xen/common: introduce a
From: Paul Durrant
The code is invoked when a SHARED_INFO record is processed but actually
performs two functions:
[1] Copy the 'vcpu_info' and 'arch' substructures from the record into the
new domain's shared_info
[2] Clear out any pending event channel state, mask all channels and also
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
Reviewed-by: Julien Grall
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Stefano Stabellini
v4:
- Add missing zero
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: Processing of the content during restore is currently limited to
PV domains, and matches processing of the PV-only SHARED_INFO record
done by libxc. All content is, however, saved such
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: Whilst the record definition is x86 specific, it is visible directly
in the common header as context record numbers should be unique across
all architectures.
Signed-off-by: Paul Durra
From: Paul Durrant
A new 'domain context' framework was recently introduced to facilitate
transfer of state for both PV and HVM guests. Hence this patch mandates the
presence of a new DOMAIN_CONTEXT record in version 4 of the libxc migration
stream.
This record will incorprate the content of the
From: Paul Durrant
The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have
sections explaining what they are but their values are not defined. Indeed
their values are defined as "Reserved for future mandatory records."
Also, the spec revision is adjusted to match the migration
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
---
Cc: Andrew Cooper
Cc: Wei Liu
NOTE: Ian requested ack from Andrew
v3:
- Re-worked to avoid c
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a doma
Hi Stefano,
On 17/08/2020 23:56, Stefano Stabellini wrote:
On Sat, 15 Aug 2020, Julien Grall wrote:
From: Julien Grall
The IOREQ code is using cmpxchg() with 64-bit value. At the moment, this
is x86 code, but there is plan to make it common.
To cater 32-bit arch, introduce two new helpers to
From: Paul Durrant
... and bump the version.
This patch implements version 4 of the migration stream by adding the code
necessary to save and restore DOMAIN_CONTEXT records, and removing the code
to save the SHARED_INFO and TSC_INFO records (as these are deprecated in
version 4).
Signed-off-by:
On 18/08/2020 11:13, Bertrand Marquis wrote:
Hi,
>> On 18 Aug 2020, at 10:42, André Przywara wrote:
>>
>> On 18/08/2020 10:25, Bertrand Marquis wrote:
>>
>> Hi,
>>
On 18 Aug 2020, at 10:14, André Przywara wrote:
On 18/08/2020 04:11, Wei Chen wrote:
Hi Wei,
> Xe
On 18.08.2020 11:12, Julien Grall wrote:
> Hi Jan,
>
> On 18/08/2020 09:57, Jan Beulich wrote:
>> On 18.08.2020 10:53, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 18/08/2020 09:39, Jan Beulich wrote:
On 14.08.2020 21:25, Julien Grall wrote:
> Hi Andrew,
>
> Sorry for the late answe
On Mon, 2020-08-17 at 14:56 +0200, Christian Lindig wrote:
> This all looks good - I left a small comment on one of the patches
> and I agree that this needs testing. I also wonder about
> compatibility with earlier OCaml releases that we support but I see
> no real obstacles.
>
I've developed th
On 18.08.2020 12:13, Julien Grall wrote:
> Hi Jan,
>
> On 18/08/2020 09:49, Jan Beulich wrote:
>> On 13.08.2020 19:22, Julien Grall wrote:
>>> Hi,
>>>
>>> On 13/08/2020 17:08, Hongyan Xia wrote:
On Fri, 2020-08-07 at 16:05 +0200, Jan Beulich wrote:
> On 27.07.2020 16:21, Hongyan Xia wrote
On 18.08.2020 10:58, Julien Grall wrote:
>
>
> On 18/08/2020 09:50, Jan Beulich wrote:
>> On 14.08.2020 21:07, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 31/07/2020 12:36, Jan Beulich wrote:
On 30.07.2020 20:18, Julien Grall wrote:
> From: Julien Grall
>
> Only a few places are
On Mon, Aug 17, 2020 at 10:16:07AM +0200, Ard Biesheuvel wrote:
> > @@ -331,7 +333,8 @@ void __init efi_esrt_init(void)
> >
> > end = esrt_data + size;
> > pr_info("Reserving ESRT space from %pa to %pa.\n", &esrt_data,
> > &end);
> > - if (md.type == EFI_BOOT_SERVICES_DATA)
>
On 18/08/2020 12:27, Jan Beulich wrote:
On 18.08.2020 11:12, Julien Grall wrote:
As pointed
out before, ACCESS_ONCE() and {read,write}_atomic() serve slightly
different purposes, and so far it looks like all of us are lacking ideas
on how to construct something that catches all cases by one s
On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
> > In case of Xen PV dom0, Xen passes along info about system tables (see
> > arch/x86/xen/efi.c), but not the memory map from EFI.
>
> I think that's bec
On Mon, Aug 17, 2020 at 06:56:24PM +0100, Julien Grall wrote:
>
>
> On 17/08/2020 18:33, Roger Pau Monné wrote:
> > On Mon, Aug 17, 2020 at 04:53:51PM +0100, Julien Grall wrote:
> > >
> > >
> > > On 17/08/2020 16:03, Roger Pau Monné wrote:
> > > > On Mon, Aug 17, 2020 at 03:39:52PM +0100, Julie
On Wed, Jul 22, 2020 at 05:53:00PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> Even if we assigned pirq->arch.irq to a variable, a compile is still
> allowed to read pirq->arch.irq multiple time. This means that the value
> checked may be different from the value used to get the desc.
>
Hi Jan,
On 18/08/2020 12:30, Jan Beulich wrote:
On 18.08.2020 12:13, Julien Grall wrote:
Hi Jan,
On 18/08/2020 09:49, Jan Beulich wrote:
On 13.08.2020 19:22, Julien Grall wrote:
Hi,
On 13/08/2020 17:08, Hongyan Xia wrote:
On Fri, 2020-08-07 at 16:05 +0200, Jan Beulich wrote:
On 27.07.2020
On 18/08/2020 12:32, Jan Beulich wrote:
On 18.08.2020 10:58, Julien Grall wrote:
One option. Personally I'd prefer to avoid introduction of yet another
constant, by leveraging __XEN_GUEST_ACCESS_H__ instead.
I thought about it but it doesn't prevent new inclusions of asm/guest_access.h.
Fo
I see little reason to support old OCaml releases and requiring OCaml 4.06
would be fine with me but I assume that the project might have its own ideas
about this.
From: Edwin Torok
Sent: 18 August 2020 08:28
To: Christian Lindig; xen-devel@lists.xenproje
> On 18 Aug 2020, at 12:22, André Przywara wrote:
>
> On 18/08/2020 11:13, Bertrand Marquis wrote:
>
> Hi,
>
>>> On 18 Aug 2020, at 10:42, André Przywara wrote:
>>>
>>> On 18/08/2020 10:25, Bertrand Marquis wrote:
>>>
>>> Hi,
>>>
> On 18 Aug 2020, at 10:14, André Przywara wrote:
This patch serie is adding Neoverse N1 processor identification and
enabling the processor errata 1165522 for Neoverse N1 processors.
Bertrand Marquis (2):
arm: Add Neoverse N1 processor identifation
xen/arm: Enable CPU Errata 1165522 for Neoverse
xen/arch/arm/cpuerrata.c| 8 +++-
Enable CPU errata of Speculative AT on the Neoverse N1 processor
versions r0p0 to r2p0.
Also Fix Cortex A76 Errata string which had a wrong errata number.
Signed-off-by: Bertrand Marquis
---
xen/arch/arm/cpuerrata.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/a
Add MIDR and CPU part numbers for Neoverse N1
Signed-off-by: Bertrand Marquis
---
xen/include/asm-arm/processor.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index aa642e3ab2..3ca67f8157 100644
--- a/xen/include/asm-arm/
Hi Bertrand,
Title: s/identifation/identification/
On 18/08/2020 14:47, Bertrand Marquis wrote:
Add MIDR and CPU part numbers for Neoverse N1
Signed-off-by: Bertrand Marquis
I can fix the typo on commit:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
> On 18 Aug 2020, at 15:07, Julien Grall wrote:
>
> Hi Bertrand,
>
> Title: s/identifation/identification/
oh yes sorry :-)
>
> On 18/08/2020 14:47, Bertrand Marquis wrote:
>> Add MIDR and CPU part numbers for Neoverse N1
>> Signed-off-by: Bertrand Marquis
>
> I can fix the typo on commi
Hi Bertrand,
There is only one. So it should be erratum :).
On 18/08/2020 14:47, Bertrand Marquis wrote:
Enable CPU errata of Speculative AT on the Neoverse N1 processor
Ditto.
versions r0p0 to r2p0.
Also Fix Cortex A76 Errata string which had a wrong errata number.
Ditto.
And good catch
On Thu, Jul 23, 2020 at 02:59:57PM +0100, Andrew Cooper wrote:
> On 23/07/2020 14:22, Julien Grall wrote:
> > Hi Jan,
> >
> > On 23/07/2020 12:23, Jan Beulich wrote:
> >> On 22.07.2020 18:53, Julien Grall wrote:
> >>> --- a/xen/arch/x86/irq.c
> >>> +++ b/xen/arch/x86/irq.c
> >>> @@ -1187,7 +1187,7
> On 18 Aug 2020, at 15:10, Julien Grall wrote:
>
> Hi Bertrand,
>
> There is only one. So it should be erratum :).
True my years of latin are quite far ;-)
Anyway grep for errata in commit logs would be defeated if we put erratum
instead of errata.
>
> On 18/08/2020 14:47, Bertrand Marqu
On 18/08/2020 10:34, Olaf Hering wrote:
> Since commit 6b85e427098cce1a6d386b3bae2f0c7ce86e47f7 'xen-cpuid -p' shows
> the cpuid policies. I think these policies define what a domU will get to see
> when cpuid() is invoked, or when MSRs are accessed.
Only a subset of the read-only MSRs - those w
On Tue, Aug 18, 2020 at 02:47:10PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
> > Do you mean PV dom0 should receive full EFI memory map? Jan already
> > objected this as it would be a layering violation.
>
> dom0 is already capable
On 18.08.2020 15:14, Julien Grall wrote:
>
>
> On 18/08/2020 12:32, Jan Beulich wrote:
>> On 18.08.2020 10:58, Julien Grall wrote:
One option. Personally I'd prefer to avoid introduction of yet another
constant, by leveraging __XEN_GUEST_ACCESS_H__ instead.
>>>
>>> I thought about it bu
On 18.08.2020 13:52, Julien Grall wrote:
>
>
> On 18/08/2020 12:27, Jan Beulich wrote:
>> On 18.08.2020 11:12, Julien Grall wrote:
As pointed
out before, ACCESS_ONCE() and {read,write}_atomic() serve slightly
different purposes, and so far it looks like all of us are lacking ideas
On 18.08.2020 15:08, Julien Grall wrote:
> Hi Jan,
>
> On 18/08/2020 12:30, Jan Beulich wrote:
>> On 18.08.2020 12:13, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 18/08/2020 09:49, Jan Beulich wrote:
On 13.08.2020 19:22, Julien Grall wrote:
> Hi,
>
> On 13/08/2020 17:08, Hongyan Xi
On 18/08/2020 17:04, Jan Beulich wrote:
On 18.08.2020 15:14, Julien Grall wrote:
On 18/08/2020 12:32, Jan Beulich wrote:
On 18.08.2020 10:58, Julien Grall wrote:
One option. Personally I'd prefer to avoid introduction of yet another
constant, by leveraging __XEN_GUEST_ACCESS_H__ instead.
On 18.08.2020 18:20, Julien Grall wrote:
>
>
> On 18/08/2020 17:04, Jan Beulich wrote:
>> On 18.08.2020 15:14, Julien Grall wrote:
>>>
>>>
>>> On 18/08/2020 12:32, Jan Beulich wrote:
On 18.08.2020 10:58, Julien Grall wrote:
>> One option. Personally I'd prefer to avoid introduction of ye
Hi Jan,
On 18/08/2020 17:23, Jan Beulich wrote:
On 18.08.2020 18:20, Julien Grall wrote:
On 18/08/2020 17:04, Jan Beulich wrote:
On 18.08.2020 15:14, Julien Grall wrote:
On 18/08/2020 12:32, Jan Beulich wrote:
On 18.08.2020 10:58, Julien Grall wrote:
One option. Personally I'd prefer to
Hi Julien,
Somehow we stopped on this thread and you did already most of the work so I
think we should try to finish what you started
> On 4 Jul 2020, at 17:07, Julien Grall wrote:
>
> On 17/06/2020 17:23, Julien Grall wrote:
>> Hi,
>> On 16/06/2020 22:24, Stefano Stabellini wrote:
>>> On Tue
Ian Jackson writes ("[PATCH 1/1] docs/process/branching-checklist: Get osstest
branch right"):
> The runes for this manual osstest were wrong. It needs to run as
> osstest, and cr-for-branches should be run from testing.git.
>
> Signed-off-by: Ian Jackson
Not sure if I need an ack for this but
On 18/08/2020 10:25, Christian Lindig wrote:
> I see little reason to support old OCaml releases and requiring OCaml 4.06
> would be fine with me but I assume that the project might have its own ideas
> about this.
>
>
> From: Edwin Torok
> Sent: 18 August
Stefano Stabellini writes ("[PATCH 01/14] kernel-doc: public/arch-arm.h"):
> From: Stefano Stabellini
>
> Convert in-code comments to kernel-doc format wherever possible.
Thanks. But, err, I think there is not yet any in-tree machinery for
actually building and publishing these kernel-doc comme
On 18/08/2020 17:35, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
Somehow we stopped on this thread and you did already most of the work so I
think we should try to finish what you started
Sorry this fell-through the cracks. I have a new version for patch #1,
but not yet patch #2.
On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
> > On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
> > > In case of Xen PV dom0, Xen passes along info about system tables (see
Stefano Stabellini writes ("Re: [PATCH 00/14] kernel-doc: public/arch-arm.h"):
> I am replying to this email as I have been told that the original was
> filtered as spam due to the tarball attachment. The tarball contains
> some example html output document files from sphinx.
Thanks.
Thanks for a
On Fri, Aug 07, 2020 at 01:32:38PM +0200, Jan Beulich wrote:
> There's no need for xen.efi at all, and there's also no need for EFI
> support in xen.gz since the shim runs in PVH mode, i.e. without any
> firmware (and hence by implication also without EFI one).
>
> The slightly odd looking use of
On Fri, Aug 07, 2020 at 01:35:08PM +0200, Jan Beulich wrote:
> There is no need for platform-wide, system-wide, or per-domain control
> in this case. Hence avoid including this dead code in the build.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
One comment below.
>
> --- a/xe
Hi Bertrand,
On 18/08/2020 18:06, Bertrand Marquis wrote:
On 18 Aug 2020, at 17:43, Julien Grall wrote:
On 18/08/2020 17:35, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
Somehow we stopped on this thread and you did already most of the work so I
think we should try to finish what
> On 18 Aug 2020, at 17:43, Julien Grall wrote:
>
>
>
> On 18/08/2020 17:35, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>> Somehow we stopped on this thread and you did already most of the work so I
>> think we should try to finish what you started
>
> Sorry this fell-throug
On 17/08/2020 16:57, Roger Pau Monne wrote:
> @@ -1005,6 +1013,13 @@ static int write_msr(unsigned int reg, uint64_t val,
> curr->arch.pv.gs_base_user = val;
> return X86EMUL_OKAY;
>
> +case MSR_EFER:
> +/* Silently drop writes that don't change the reported value. *
On 17/08/2020 16:57, Roger Pau Monne wrote:
> The value in the PAT MSR is part of the ABI between Xen and PV guests,
> and there's no reason to not allow a PV guest to read it.
This is faster than using RDMSR to find the constant.
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
(Can
Now that the main PV/HVM MSR handlers raise #GP for all unknown MSRs, there is
no need to special case these MSRs any more.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/msr.c | 46 --
1 file chang
On 17/08/2020 16:57, Roger Pau Monne wrote:
> Linux PV guests will attempt to read the FEATURE_CONTROL MSR, report
> no features enabled or available, and that the MSR is already locked.
>
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/pv/emul-priv-op.c | 4
> 1 file changed, 4 insert
On Tue, Aug 18, 2020 at 02:50:24PM +0100, Andrew Cooper wrote:
> On 17/08/2020 16:57, Roger Pau Monne wrote:
> > The value in the PAT MSR is part of the ABI between Xen and PV guests,
> > and there's no reason to not allow a PV guest to read it.
>
> This is faster than using RDMSR to find the cons
On 17/08/2020 16:57, Roger Pau Monne wrote:
> From: Andrew Cooper
>
> Change the catch-all behavior for MSR not explicitly handled. Instead
> of allow full read-access to the MSR space and silently dropping
> writes return an exception when the MSR is not explicitly handled.
>
> Signed-off-by: And
On 17/08/2020 16:57, Roger Pau Monne wrote:
> Change the catch-all behavior for MSR not explicitly handled. Instead
> of allow full read-access to the MSR space and silently dropping
> writes return an exception when the MSR is not explicitly handled.
>
> Signed-off-by: Roger Pau Monné
Acked-by:
On 17/08/2020 16:57, Roger Pau Monne wrote:
> Linux PV guests will attempt to read the APIC_BASE MSR, so just report
> a default value to make Linux happy.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
This is a massive layering violation, but we're a decade too late to fix
it :(
On Tue, Aug 18, 2020 at 07:21:14PM +0200, Roger Pau Monné wrote:
> > Let me draw the picture from the beginning.
>
> Thanks, greatly appreciated.
>
> > EFI memory map contains various memory regions. Some of them are marked
> > as not needed after ExitBootServices() call (done in Xen before
> > l
On 17/08/2020 16:57, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index ca3bbfcbb3..671cdcb724 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1917,6 +1917,13 @@ static int svm_msr_read_intercept(unsigned int msr,
Jürgen Groß writes ("Re: [PATCH] qemu-trad: remove Xen path dependencies"):
> On 15.07.20 11:01, Juergen Gross wrote:
> > xen-hhoks.mak contains hard wired paths for the used libraries of
> > qemu-trad. Replace those by the make variables from Xen's Rules.mk,
> > which is already included.
> >
> >
On 17/08/2020 16:57, Roger Pau Monne wrote:
> Such handling consist in checking that no bits have been changed from
> the read value, if that's the case silently drop the write, otherwise
> inject a fault.
>
> At least Windows guests will expect to write to the MISC_ENABLE MSR
> with the same value
When ipxe.bin is missing, make uninstall will fail due to
wrong switch (-r) passed to rm command. Replace it with -f.
Signed-off-by: Hubert Jasudowicz
---
tools/firmware/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
Ian Jackson writes ("Re: Planned osstest outage, around 17th August"):
> Some of the upgrades have encountered difficulties. Nothing
> insurmountable, but it is taking longer than expected. We hope to be
> done some time tomorrow. In the meantime osstest is still offline.
Unfortunately we are s
On Tue, Aug 18, 2020 at 05:00:20PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 18, 2020 at 02:47:10PM +0200, Roger Pau Monné wrote:
> > On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
> > > Do you mean PV dom0 should receive full EFI memory map? Jan already
>
Hi!
first things first -- booting on those devices have always
required efi=no-rs -- but it seems that Xen 4.14 is now
busted at a more fundamental level. I'm attaching two
boot sequences (one with kernel 4.19.5 and one with 5.4.51)
in the hopes that this may provide some clues right away.
Any he
Hi Andrew!
thanks for replying so quickly -- much appreciated.
On Tue, Aug 18, 2020 at 3:20 PM Andrew Cooper
wrote:
> On 18/08/2020 23:09, Roman Shaposhnik wrote:
> > Hi!
> >
> > first things first -- booting on those devices have always
> > required efi=no-rs
>
> That is a bug. Please start a
1 - 100 of 104 matches
Mail list logo
