Juergen Gross, le jeu. 19 août 2021 07:30:56 +0200, a ecrit:
> Commit 4821876fcd2ff ("mini-os: netfront: fix suspend/resume handling")
> introduced a NULL pointer dereference in the initialization of netfront
> in the case of no IP address being set in Xenstore.
>
> Fix that by testing this condit
PING!!!
On 16.07.21 08:47, Juergen Gross wrote:
Ping?
On 02.07.21 16:29, Juergen Gross wrote:
The core of a pv linux guest produced via "xl dump-core" is not usable
as since kernel 4.14 only the linear p2m table is kept if Xen indicates
it is supporting that. Unfortunately xc_core_arch_map_p2m
... an already not mapped page. With all other exit paths doing the
unmap, I have no idea how I managed to miss that aspect at the time.
Fixes: ad591454f069 ("AMD/IOMMU: don't needlessly trigger errors/crashes when
unmapping a page")
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/
The old (super)page's permissions ought to be propagated, rather than
blindly allowing both reads and writes.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -231,7 +231,7 @@ static int iommu_pde_from_dfn(struct dom
While for context cache entry flushing use of did 0 is indeed correct
(after all upon reading the context entry the IOMMU wouldn't know any
domain ID if the entry is not present, and hence a surrogate one needs
to be used), for IOTLB entries the normal domain ID (from the [present]
context entry) g
On 18.08.2021 19:44, Julien Grall wrote:
> On 18/08/2021 08:52, Jan Beulich wrote:
>> Ranges checked by iomem_access_permitted() are inclusive; to permit a
>> mapping there's no need for access to also have been granted for the
>> subsequent page.
>
> Good catch! OOI, how did you find it?
In the
On 18.08.2021 17:09, Ian Jackson wrote:
> We haven't formally appointed a release manager for Xen 4.16.
> I was approached and asked if I would do the job, and said yes,
> but I think things got stuck there. Taking this as a prima
> faciae indication of community confidence, I hereby volunteer to
On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote:
> Hi Christoph:
> Sorry to bother you.Please double check with these two patches
> " [PATCH V3 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function
> for HV IVM" and "[PATCH V3 09/13] DMA: Add dma_map_decrypted/dma_
> unmap_
On 05.07.21 17:12, Jan Beulich wrote:
For log-dirty operations a 64-bit field is being truncated to become an
"int" return value. Seeing the large number of arguments the present
function takes, reduce its set of parameters to that needed for all
operations not involving the log-dirty bitmap, whi
flight 164240 linux-5.4 real [real]
flight 164250 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164240/
http://logs.test-lab.xenproject.org/osstest/logs/164250/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On 13.08.2021 13:37, Ian Jackson wrote:
> The current policy for minimum supported versions of tools, compilers,
> etc. is unsatisfactory: For many dependencies no minimum version is
> specified. For those where a version is stated, updating it is a
> decision that has to be explicitly taken for t
On 19.08.2021 11:11, Juergen Gross wrote:
> On 05.07.21 17:12, Jan Beulich wrote:
>> For log-dirty operations a 64-bit field is being truncated to become an
>> "int" return value. Seeing the large number of arguments the present
>> function takes, reduce its set of parameters to that needed for all
flight 164242 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 19.08.21 11:24, Jan Beulich wrote:
On 19.08.2021 11:11, Juergen Gross wrote:
On 05.07.21 17:12, Jan Beulich wrote:
For log-dirty operations a 64-bit field is being truncated to become an
"int" return value. Seeing the large number of arguments the present
function takes, reduce its set of pa
On 8/19/2021 4:49 PM, Christoph Hellwig wrote:
On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote:
Hi Christoph:
Sorry to bother you.Please double check with these two patches
" [PATCH V3 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function
for HV IVM" and "[PATCH V3 09
On Thu, Aug 19, 2021 at 05:59:02PM +0800, Tianyu Lan wrote:
>
>
> On 8/19/2021 4:49 PM, Christoph Hellwig wrote:
>> On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote:
>>> Hi Christoph:
>>>Sorry to bother you.Please double check with these two patches
>>> " [PATCH V3 10/13] x86/Swio
flight 164249 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164249/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 8/19/2021 6:02 PM, Christoph Hellwig wrote:
On Thu, Aug 19, 2021 at 05:59:02PM +0800, Tianyu Lan wrote:
On 8/19/2021 4:49 PM, Christoph Hellwig wrote:
On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote:
Hi Christoph:
Sorry to bother you.Please double check with these two p
On 05.07.21 17:13, Jan Beulich wrote:
In send_memory_live() the precise value the dirty_count struct field
gets initialized to doesn't matter much (apart from the triggering of
the log message in send_dirty_pages(), see below), but it is important
that it not be zero on the first iteration (or el
Hi all,
I tried to run virtio-net on X86 machine according to the Wiki page
https://wiki.xenproject.org/wiki/Virtio_On_Xen.
And I Encountered some confusing problems.
The Qemu version I used is QEMU emulator version 4.2.1 (Debian
1:4.2-3ubuntu6.17)
The content of guest.cfg is as below:
type =
On 19.08.2021 12:20, Juergen Gross wrote:
> On 05.07.21 17:13, Jan Beulich wrote:
>> In send_memory_live() the precise value the dirty_count struct field
>> gets initialized to doesn't matter much (apart from the triggering of
>> the log message in send_dirty_pages(), see below), but it is importan
On 18.08.2021 16:15, Paul Durrant wrote:
> On 18/08/2021 13:09, Jan Beulich wrote:
>> On 18.08.2021 12:51, Jan Beulich wrote:
>>> back at the time I did already question your intended meaning of
>>> this flag. I notice that there's presently no consumer of it being
>>> set (apart from yielding non-
On 19.08.21 13:06, Jan Beulich wrote:
On 19.08.2021 12:20, Juergen Gross wrote:
On 05.07.21 17:13, Jan Beulich wrote:
In send_memory_live() the precise value the dirty_count struct field
gets initialized to doesn't matter much (apart from the triggering of
the log message in send_dirty_pages(),
On Wed, Aug 18, 2021 at 01:44:31PM +0100, Andrew Cooper wrote:
> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> > set_xcr0() and set_msr_xss() use cached value to avoid setting the
> > register to the same value over and over. But suspend/resume implicitly
> > reset the registers and sinc
On 19.08.2021 13:25, Juergen Gross wrote:
> On 19.08.21 13:06, Jan Beulich wrote:
>> On 19.08.2021 12:20, Juergen Gross wrote:
>>> On 05.07.21 17:13, Jan Beulich wrote:
In send_memory_live() the precise value the dirty_count struct field
gets initialized to doesn't matter much (apart from
On 19.08.2021 13:51, Jan Beulich wrote:
> On 19.08.2021 13:25, Juergen Gross wrote:
>> On 19.08.21 13:06, Jan Beulich wrote:
>>> On 19.08.2021 12:20, Juergen Gross wrote:
On 05.07.21 17:13, Jan Beulich wrote:
> In send_memory_live() the precise value the dirty_count struct field
> gets
Jan Beulich writes ("Re: [PATCH] RFC: Version support policy"):
> On 13.08.2021 13:37, Ian Jackson wrote:
> > The current policy for minimum supported versions of tools, compilers,
> > etc. is unsatisfactory: For many dependencies no minimum version is
> > specified. For those where a version is s
On 19.08.2021 13:55, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] RFC: Version support policy"):
>> On 13.08.2021 13:37, Ian Jackson wrote:
>>> In this patch I propose a cutoff of 6 years.
>>> Obviously there will be debate about the precise value.
>>
>> Indeed I consider this way too shor
Hello All,
The purpose of this patch series is to add PCI passthrough support to Xen on
Arm. PCI passthrough support on ARM is the collaboration work between EPAM and
ARM. ARM submitted the partial RFC [1][2] last year to get early feedback. We
tried to fix all the comments and added more features
MSI code that implements MSI functionality to support MSI within XEN is
not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI flag to gate
the code for ARM.
No functional change intended.
Signed-off-by: Rahul Singh
---
xen/arch/x86/Kconfig | 1 +
xen/drivers/passthrough/Makefil
Compilation error is observed when HAS_PCI is enabled for ARM
architecture.
Add definition for arch_iommu_use_permitted() and
arch_pci_clean_pirqs().Implement dummy functions for pci_conf_read*() to
fix compilation error.
pci.c: In function ‘deassign_device’:
pci.c:849:49: error: implicit declara
Compilation error is observed when ACPI and HAS_PCI is enabled for ARM
architecture. Move the code under CONFIG_X86 flag to gate the code for
ARM.
No functional change intended.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
pci_init(..) will be called during xen startup to initialize and probe
the PCI host-bridge driver.
Signed-off-by: Rahul Singh
---
xen/arch/arm/pci/pci.c | 54
xen/include/asm-arm/device.h | 1 +
2 files changed, 55 insertions(+)
diff --git a/xen/arch/
On 19.08.2021 05:07, osstest service owner wrote:
> flight 164237 xen-unstable real [real]
> flight 164246 xen-unstable real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/164237/
> http://logs.test-lab.xenproject.org/osstest/logs/164246/
>
> Regressions :-(
>
> Tests which did
XEN during boot will read the PCI device tree node “reg” property
and will map the PCI config space to the XEN memory.
As of now "pci-host-ecam-generic" compatible board is supported.
"linux,pci-domain" device tree property assigns a fixed PCI domain
number to a host bridge, otherwise an unstable
Add support for PCI ecam operations to access the PCI
configuration space.
Signed-off-by: Rahul Singh
---
xen/arch/arm/pci/Makefile | 1 +
xen/arch/arm/pci/ecam.c | 63 +
xen/arch/arm/pci/pci-access.c | 53
xen/arc
From: Oleksandr Andrushchenko
Add support for Xilinx ZynqMP PCI host controller to map the PCI config
space to the XEN memory.
Signed-off-by: Oleksandr Andrushchenko
---
xen/arch/arm/pci/Makefile | 1 +
xen/arch/arm/pci/pci-host-zynqmp.c | 59 ++
2 files c
Implement generic pci access functions to read/write the configuration
space.
Signed-off-by: Rahul Singh
---
xen/arch/arm/pci/pci-access.c | 31 +-
xen/arch/arm/pci/pci-host-common.c | 19 ++
xen/include/asm-arm/pci.h | 2 ++
3 files cha
Add cmdline boot option "pci=on" to enable/disable the PCI init during
boot.
Signed-off-by: Rahul Singh
---
xen/arch/arm/pci/pci.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/xen/arch/arm/pci/pci.c b/xen/arch/arm/pci/pci.c
index d1c9cf997d..dc63bbc2a2 1006
Hardware domain is in charge of doing the PCI enumeration and will
discover the PCI devices and then will communicate to XEN via hyper
call PHYSDEVOP_pci_device_add to add the PCI devices in XEN.
Signed-off-by: Rahul Singh
---
xen/arch/arm/physdev.c | 39 ---
The existing VPCI support available for X86 is adapted for Arm.
When the device is added to XEN via the hyper call
“PHYSDEVOP_pci_device_add”, VPCI handler for the config space
access is added to the Xen to emulate the PCI devices config space.
A MMIO trap handler for the PCI ECAM space is registe
libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during guest boot.
Emulated PCI device tree node will only be created when there is any
device assigned to guest.
A new area has been reserved in the arm guest physical map at
w
XEN_DOMCTL_ioport_permission, PHYSDEVOP_unmap_pirq, PHYSDEVOP_unmap_pirq
are unimplemented for ARM. When libxl assigning a PCI device to the
guest error is observed related to above functions.
Implement dummy functions to fix the error.
Signed-off-by: Rahul Singh
---
xen/arch/arm/domctl.c | 2
If the property is not present in the device tree node for host bridge,
XEN while creating the dtb for hwdom will create this property and
assigns the already allocated segment to the host bridge
so that XEN and linux will have the same segment for the host bridges.
Signed-off-by: Rahul Singh
---
On 19.08.2021 14:02, Rahul Singh wrote:
> Add cmdline boot option "pci=on" to enable/disable the PCI init during
> boot.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/pci/pci.c | 30 ++
> 1 file changed, 30 insertions(+)
Any addition or change of a command line
On 19.08.2021 14:02, Rahul Singh wrote:
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -173,6 +173,8 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
> domain *d,
>
> return rc;
> }
> +case XEN_DOMCTL_ioport_permission:
> +return 0;
I don't th
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
MSI code that implements MSI functionality to support MSI within XEN is
not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI flag to gate
Can you clarify what you mean by not usable? Is it because we lack of
support or we have no plan to
On 17.08.21 16:18, Jan Beulich wrote:
Old enough glibc has clock_gettime() in librt.so, hence the library
needs to be specified to the linker. Newer glibc has the symbol
available in both libraries, so make sure that libc.so is preferred (to
avoid an unnecessary dependency on librt.so).
Fixes: 9
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
Compilation error is observed when HAS_PCI is enabled for ARM
architecture.
To be pedantic, what you are trying to solve is not a compilation error
but the fact that the PCI mandates helpers that doesn't yet exist on
Arm. So...
Add definit
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
Add cmdline boot option "pci=on" to enable/disable the PCI init during
boot.
I read this as "PCI" will be either disabled/enabled for the platform.
Whereas, I think it will be used to decide whether Xen discover PCI and
PCI passthrough is sup
(+ Jan)
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
Hardware domain is in charge of doing the PCI enumeration and will
discover the PCI devices and then will communicate to XEN via hyper
call PHYSDEVOP_pci_device_add to add the PCI devices in XEN.
There are other PHYSDEVOP operations to
Hi,
On 19/08/2021 13:12, Jan Beulich wrote:
On 19.08.2021 14:02, Rahul Singh wrote:
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -173,6 +173,8 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
domain *d,
return rc;
}
+case XEN_DOMCTL_ioport_permissi
Jan Beulich writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
> Looks like this didn't sort itself (yet). Do you continue to be
> convinced that it will, eventually?
Indeed not. The error message is different now. The guest installer
reports
2021-08-18 18:14:09 Z 172.16.146.47:5890
Jan Beulich writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
> Looks like this didn't sort itself (yet). Do you continue to be
> convinced that it will, eventually?
Hooray for explanations in commit messages.
I will (1) drop this test and (2) force push staging in the meantime.
Ian
Hi Rahul,
On 19/08/2021 13:02, Rahul Singh wrote:
libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during guest boot.
Emulated PCI device tree node will only be created when there is any
device assigned to guest.
A new area
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Current putn function that is using for early print
only can print low 32-bit of AArch64 register. This
will lose some important messages while debugging
with early console. For example:
(XEN) Bringing up CPU5
- CPU 00010100 booting -
Will be
On 19.08.21 14:45, Ian Jackson wrote:
Jan Beulich writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
Looks like this didn't sort itself (yet). Do you continue to be
convinced that it will, eventually?
Hooray for explanations in commit messages.
I will (1) drop this test and (2) fo
Juergen Gross writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
> Does this mean we should de-support pvgrub? Or even remove it?
I think so.
> BTW, I don't see any reason why someone would want to keep using pvgrub
> with grub-pv being available...
Precisely.
Ian.
Ian Jackson writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
> I will (1) drop this test and (2) force push staging in the meantime.
Force pushed xen-unstable staging. osstest commit is below.
Ian.
>From 8dee6e333622d830b7a9373989f63b526a85cd94 Mon Sep 17 00:00:00 2001
From: Ian J
Juergen Gross writes ("Re: [xen-unstable test] 164237: regressions - FAIL"):
> Does this mean we should de-support pvgrub? Or even remove it?
>
> BTW, I don't see any reason why someone would want to keep using pvgrub
> with grub-pv being available...
I went to change its status in SUPPORT.md and
We can no longer conveniently even test pv-grub1; osstest tests for
this have just been dropped from all Xen branches
(by osstest.git#8dee6e333622).
This is without prejudice to its eventual removal. We should perhaps
proceed cautiously with that since it may be helpful for some old
guests.
Unde
Hi,
On 11/08/2021 11:23, Wei Chen wrote:
From: Hongda Deng
In current code, arch_get_dma_bitsize will return 32 when platorm
or platform->dma_bitsize is not set. It's not resonable, for Arm,
s/resonable/reasonable/
we don't require to reserve DMA memory. So we set dma_bitsize always
be 0.
Hi,
I guess this patch may be dropped after my comment on patch #4. I will
comment just on the process.
On 11/08/2021 11:23, Wei Chen wrote:
From: Hongda Deng
In previous patch, we make arch_get_dma_bitsize return 0 when
dma_bitsize and platform->dma_bitsize are not set. But this
will affec
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Only Arm64 supports NUMA, the CONFIG_NUMA could not be
enabled for Arm32.
What do you mean by "could not be enabled"?
Even in Arm64, users still can disable
the CONFIG_NUMA through Kconfig option. In this case, keep
current fake NUMA API, will mak
Hi,
On 11/08/2021 11:24, Wei Chen wrote:
We need a Kconfig option to distinguish with ACPI based
NUMA. So we introduce the new Kconfig option:
DEVICE_TREE_NUMA in this patch for Arm64.
Signed-off-by: Wei Chen
---
xen/arch/arm/Kconfig | 10 ++
1 file changed, 10 insertions(+)
diff -
On 19.08.2021 14:35, Julien Grall wrote:
> On 19/08/2021 13:02, Rahul Singh wrote:
>> Hardware domain is in charge of doing the PCI enumeration and will
>> discover the PCI devices and then will communicate to XEN via hyper
>> call PHYSDEVOP_pci_device_add to add the PCI devices in XEN.
>
> There
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Xen memory allocation and scheduler modules are NUMA aware.
But actually, on x86 has implemented the architecture APIs
to support NUMA. Arm was providing a set of fake architecture
APIs to make it compatible with NUMA awared memory allocation
and sche
On 19.08.21 15:26, Ian Jackson wrote:
We can no longer conveniently even test pv-grub1; osstest tests for
this have just been dropped from all Xen branches
(by osstest.git#8dee6e333622).
This is without prejudice to its eventual removal. We should perhaps
proceed cautiously with that since it m
Juergen Gross writes ("Re: [PATCH] SUPPORT.md: Explicitly desupport pvgrub1;
and support grub-pv"):
> Probably, yes. OTOH keeping just old binaries should work without
> any problem. This might be worth considering.
Mmm.
> > +### x86/HVM pvgrub1 (aka stubdom pv-grub)
>
> s/HVM/PV/
Oops, fixed
Hi Julien,
> On 19 Aug 2021, at 14:42, Julien Grall wrote:
>
> Hi Wei,
>
> On 11/08/2021 11:23, Wei Chen wrote:
>> Xen memory allocation and scheduler modules are NUMA aware.
>> But actually, on x86 has implemented the architecture APIs
>> to support NUMA. Arm was providing a set of fake archit
Hello,
besides there not having been any indication what has gone wrong
(if anything in the first place), I wonder in how far the operation
of freemem() / libxl_wait_for_memory_target() is fully suitable for
all possible scenarios. I did create the guest in question on a
Dom0 running in strict mod
On Thu, Aug 19, 2021 at 10:38:49AM +, Jiamei Xie wrote:
> Hi all,
> I tried to run virtio-net on X86 machine according to the Wiki page
> https://wiki.xenproject.org/wiki/Virtio_On_Xen.
> And I Encountered some confusing problems.
>
> It seems eth0 is not virtio-net, properly a pv-net. I am
Hi Julien,
> On 19 Aug 2021, at 1:18 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 19/08/2021 13:02, Rahul Singh wrote:
>> MSI code that implements MSI functionality to support MSI within XEN is
>> not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI flag to gate
>
> Can you clarify what y
On 05.07.21 17:13, Jan Beulich wrote:
For one it is unnecessary to fill a perhaps large chunk of memory with
all ones. Add a new parameter to send_dirty_pages() for callers to
indicate so.
Then it is further unnecessary to allocate the dirty bitmap altogether
when all that's ever going to happen
On 05.07.21 17:14, Jan Beulich wrote:
Like for the dirty bitmap, it is unnecessary to allocate the deferred-
pages bitmap when all that's ever going to happen is a single all-dirty
run.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Descripti
On 19.08.21 13:51, Jan Beulich wrote:
On 19.08.2021 13:25, Juergen Gross wrote:
On 19.08.21 13:06, Jan Beulich wrote:
On 19.08.2021 12:20, Juergen Gross wrote:
On 05.07.21 17:13, Jan Beulich wrote:
In send_memory_live() the precise value the dirty_count struct field
gets initialized to doesn'
flight 164244 qemu-mainline real [real]
flight 164256 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164244/
http://logs.test-lab.xenproject.org/osstest/logs/164256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 164254 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164254/
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 1
On 17.08.2021 16:30, Andrew Cooper wrote:
> Separate the read-only hints from the features requiring active actions on
> Xen's behalf.
>
> Also take the opportunity split the IBRS/IBPB and IBPB mess. More features
> with overlapping enumeration are on the way, and and it is not useful to split
>
On 17.08.2021 16:30, Andrew Cooper wrote:
> There is a step change in speculation protections between the Zen1 and Zen2
> microarchitectures.
>
> Zen1 and older have no special support. Control bits in non-architectural
> MSRs are used to make lfence be dispatch-serialising (Spectre v1), and to
>
On 17.08.2021 16:30, Andrew Cooper wrote:
> The opencoded legacy Memory Disambiguation logic in init_amd() neglected
> Fam19h for the Zen3 microarchitecture.
>
> In practice, all Zen2 based system (AMD Fam17h Model >= 0x30 and Hygon Fam18h
> Model >= 0x4) have the architectural MSR_SPEC_CTRL and t
Jan Beulich writes ("Re: Xen 4.16: Proposed release manager and schedule"):
> On 18.08.2021 17:09, Ian Jackson wrote:
> > ** DRAFT **
> >
> > Friday 17th September Last posting date
> >
> > Patches adding new features should be posted to the mailing list
> > by this cate
Juergen Gross writes ("Re: [PATCH-4.15] tools/libs/ctrl: fix
xc_core_arch_map_p2m() to support linear p2m table"):
> Ping?
Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
> the releases are due in a couple of weeks time (and 4.14.3 is
> supposed to follow another few weeks later). Plea
On 18.08.2021 14:16, Marek Marczykowski-Górecki wrote:
> @@ -169,6 +172,29 @@ static void handle_dw_usr_busy_quirk(struct ns16550
> *uart)
> }
> }
>
> +static void enable_exar_enhanced_bits(struct ns16550 *uart)
Afaics the parameter can be pointer-to-const.
> +{
> +#ifdef NS16550_PCI
> +
On Thu, Aug 19, 2021 at 05:57:21PM +0200, Jan Beulich wrote:
> On 18.08.2021 14:16, Marek Marczykowski-Górecki wrote:
> > @@ -169,6 +172,29 @@ static void handle_dw_usr_busy_quirk(struct ns16550
> > *uart)
> > }
> > }
> >
> > +static void enable_exar_enhanced_bits(struct ns16550 *uart)
>
Juergen Gross writes ("Re: [PATCH-4.15] tools/libs/ctrl: fix
xc_core_arch_map_p2m() to support linear p2m table"):
> PING!!!
Sorry.
I have reviewed this and I think it is good to backport, so
Reviewed-by: Ian Jackson
and queued. I'll push it to staging-4.15 later today.
Ian.
On Thu, Aug 19, 2021 at 06:01:31PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 19, 2021 at 05:57:21PM +0200, Jan Beulich wrote:
> > On 18.08.2021 14:16, Marek Marczykowski-Górecki wrote:
> > > @@ -169,6 +172,29 @@ static void handle_dw_usr_busy_quirk(struct ns16550
> > > *uart)
> > >
Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
> distributions are going to want to use the latest QEMU and latest Xen,
> without needed to build two different QEMU binaries.
I think this is appropriate. Xen 4.1
In some configurations, it is safe to not overwrite the RSB on entry to Xen.
Both Intel and AMD have guidelines in this area, because of the performance
difference it makes for native kernels.
A simple microperf test, measuring the amount of time a XENVER_version
hypercall takes, shows the followi
Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
> Ian: I did take the liberty to backport Anthony's
>
> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype
Thanks.
> Beyond this I'd like the following to be considered:
>
> 6409210a5f51 libxencall: osdep_hypercal
Olaf Hering writes ("Re: preparations for 4.15.1 and 4.13.4"):
> Am Thu, 15 Jul 2021 09:58:24 +0200
> schrieb Jan Beulich :
>
> > Please point out backports you find missing from the respective staging
> > branches, but which you consider relevant.
>
> Depending on how green the CI is supposed t
Jan Beulich writes ("Re: preparations for 4.15.1 and 4.13.4"):
> On 15.07.2021 09:58, Jan Beulich wrote:
> > Beyond this I'd like the following to be considered:
> >
> > 6409210a5f51 libxencall: osdep_hypercall() should return long
> > bef64f2c0019 libxencall: introduce variant of xencall2() retur
Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more
messages]"):
> Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
> > The ABI called VERS_1.2 must be identical on all older branches to avoid
> > binary problems when rebuilding a package against old-xen+updates, and
On 19/08/2021 17:43, Ian Jackson wrote:
> Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
>> Ian: I did take the liberty to backport Anthony's
>>
>> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype
> Thanks.
>
>> Beyond this I'd like the following to be considere
Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more
messages]"):
> I thought of a better way to do this. See below for proposed patch to
> xen.git#staging.
We discussed this on IRC, and I'm going to drop this patch.
Ian.
18:00 <@andyhhp> I'm debating what to say there
18:01
On 19/08/2021 15:05, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 19 Aug 2021, at 14:42, Julien Grall wrote:
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Xen memory allocation and scheduler modules are NUMA aware.
But actually, on x86 has implemented the architecture APIs
to supp
Andrew Cooper writes ("Re: [PATCH] libs/guest: Move the guest ABI check earlier
into xc_dom_parse_image()"):
> On 17/08/2021 16:19, Jane Malalane wrote:
> > Xen may not support 32-bit PV guest for a number of reasons (lack of
> > CONFIG_PV32, explicit pv=no-32 command line argument, or implicitly
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
EFI can get memory map from EFI system table. But EFI system
table doesn't contain memory NUMA information, EFI depends on
ACPI SRAT or device tree memory node to parse memory blocks'
NUMA mapping.
But in current code, when Xen is booting from EFI, i
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
Like acpi_numa in x86 as a switch for ACPI based NUMA, we introduce
device_tree_numa as a switch for Arm device tree based NUMA. When
NUMA information in device tree is invalid, this switch will be set
to -1, then NUMA support for Arm will be disabled
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
Processor NUMA ID information is stored in device tree's processor
node as "numa-node-id". We need a new helper to parse this ID from
processor node. If we get this ID from processor node, this ID's
validity still need to be checked. Once we got a inv
1 - 100 of 139 matches
Mail list logo
