On 19.08.2021 19:50, Costin Lupu wrote:
> These changes introduce the page related definitions needed for mapping and
> accessing guests memory. These values are intended to be used by any toolstack
> component that needs to map guests memory. Until now, the values were defined
> by the xenctrl.h h
On Wed, Aug 18, 2021 at 08:35:51AM +, Wei Chen wrote:
> Hi Akashi，
>
> > -Original Message-
> > From: AKASHI Takahiro
> > Sent: 2021年8月18日 13:39
> > To: Wei Chen
> > Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> > ; Alex Benn??e ; Stratos
> > Mailing List ; virtio-dev@lists.oasis-
On 19.08.2021 21:06, Marek Marczykowski-Górecki wrote:
> Besides standard UART setup, this device needs enabling
> (vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
> control flow (MCR[2]) is ignored. Add appropriate quirk to the
> ns16550_setup_preirq(), similar to the handl
On 19.08.2021 21:06, Marek Marczykowski-Górecki wrote:
> They don't modify it, after all.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
Thanks for taking this extra step.
Jan
Clearly I neglected the special needs here, and also failed to test the
change with a debug build of Xen.
Fixes: 6b1ca51b1a91 ("x86/PV: assert page state in mark_pv_pt_pages_rdonly()")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -67,7 +67,7
On 19.08.2021 18: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 consi
On Thu, Aug 19, 2021 at 06:17:40PM +, Michael Kelley wrote:
> > +#define storvsc_dma_map(dev, page, offset, size, dir) \
> > + dma_map_page(dev, page, offset, size, dir)
> > +
> > +#define storvsc_dma_unmap(dev, dma_range, dir) \
> > + dma_unmap_page(dev, dma_range.dma,
On Thu, Aug 19, 2021 at 06:14:51PM +, Michael Kelley wrote:
> > + if (!pfns)
> > + return NULL;
> > +
> > + for (i = 0; i < size / HV_HYP_PAGE_SIZE; i++)
> > + pfns[i] = virt_to_hvpfn(buf + i * HV_HYP_PAGE_SIZE)
> > + + (ms_hyperv.shared_gpa_boundary >>
On Thu, Aug 19, 2021 at 06:11:30PM +, Michael Kelley wrote:
> This function is manipulating page tables in the guest VM. It is not involved
> in communicating with Hyper-V, or passing PFNs to Hyper-V. The pfn array
> contains guest PFNs, not Hyper-V PFNs. So it should use PAGE_SIZE
> instead
Hi Anthony,
-Original Message-
From: Anthony PERARD
Sent: 2021年8月19日 22:16
To: Jiamei Xie
Cc: xen-devel@lists.xenproject.org; Wei Chen ; nd
Subject: Re: Some questions about virtio-net on Xen x86
On Thu, Aug 19, 2021 at 10:38:49AM +, Jiamei Xie wrote:
> Hi all,
> I tried to run v
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月19日 21:38
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 17/40] xen/arm: Introduce DEVICE_TREE_NUMA
> Kconfig for arm64
>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月20日 2:13
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 22/40] xen/arm: introduce a helper to parse
> device tree process
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月20日 1:45
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 21/40] xen/arm: introduce device_tree_numa as
> a switch for devi
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月20日 1:35
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 18/40] xen/arm: Keep memory nodes in dtb for
> NUMA when boot fro
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月19日 21:34
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 07/40] xen/arm: use !CONFIG_NUMA to keep fake
> NUMA API
>
> Hi
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月19日 21:32
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 05/40] xen/arm: Fix lowmem_bitsize when
> arch_get_dma_bitsize r
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月19日 21:28
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 04/40] xen/arm: return default DMA bit width
> when platform is
flight 164252 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164252/
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-
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月19日 21:05
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 02/40] xen/arm: Print a 64-bit number in hex
> from early uart
>
flight 164255 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164255/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf bc26bc260cbfec1c6de1778ef17cf0faa54c0e03
baseline version:
xtf fc32c40a97069d4696fb7a
flight 164251 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 12 debian-di-installfail REGR. vs. 164131
test-amd64-amd64-amd6
flight 164263 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164263/
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
Besides standard UART setup, this device needs enabling
(vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
control flow (MCR[2]) is ignored. Add appropriate quirk to the
ns16550_setup_preirq(), similar to the handle_dw_usr_busy_quirk(). The
new function act on Exar 2-, 4-, and
They don't modify it, after all.
Signed-off-by: Marek Marczykowski-Górecki
---
New in v3. There was "ns16550: do not override fifo size if explicitly
set" here before, but it's already committed.
---
xen/drivers/char/ns16550.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 19/08/2021 09:03, Jan Beulich wrote:
... 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 Be
On 19/08/2021 09:04, Jan Beulich wrote:
The old (super)page's permissions ought to be propagated, rather than
blindly allowing both reads and writes.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
On 19/08/2021 09:05, Jan Beulich wrote:
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 doma
Hi Jan,
Thanks for your comments. I've just sent a v2.
Cheers,
Costin
On 8/10/21 9:41 AM, Jan Beulich wrote:
> On 09.08.2021 16:47, Costin Lupu wrote:
>> These changes introduce the page related definitions needed for mapping and
>> accessing guests memory. These values are intended to be used b
These changes refine the changes in d1b32abd which added a dependency to
xenctrl library. We use the XEN_PAGE_* definitions instead of the XC_PAGE_*
definitions and therefore we get rid of the unnecessary dependency.
Signed-off-by: Costin Lupu
---
tools/libs/gnttab/freebsd.c | 20 ++-
This series tries to fix a side-effect introduced by commits 0dbb4be7 and
d1b32abd which added a dependency to xenctrl for foreignmemory and gnntab
libraries library only because they needed to use the XC_PAGE_* values.
These changes introduce the XEN_PAGE_* definitions that will be used by any
to
These changes introduce the page related definitions needed for mapping and
accessing guests memory. These values are intended to be used by any toolstack
component that needs to map guests memory. Until now, the values were defined
by the xenctrl.h header, therefore whenever a component had to use
These changes refine the changes in 0dbb4be7 which added a dependency to
xenctrl library. We use the XEN_PAGE_* definitions instead of the XC_PAGE_*
definitions and therefore we get rid of the unnecessary dependency.
Signed-off-by: Costin Lupu
---
tools/libs/foreignmemory/core.c| 2 +-
tool
We use the values provided by the Xen public interface for defining the
XC_PAGE_* macros.
Signed-off-by: Costin Lupu
---
tools/include/xenctrl.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index b77726eab7..20313084
flight 164248 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164248/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 164178
test-amd64-i386-xl
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
Subject line tag should be "scsi: storvsc:"
> 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 vm
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
The Subject line tag should be "hv_netvsc:".
> 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 vm
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
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
> Hyper-V 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
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 invalid NUMA
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
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:
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
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
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
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 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]"):
> 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
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
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 ("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
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
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
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)
> > >
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 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)
>
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
> +
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
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
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
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:
> 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
>
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
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
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'
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 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
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 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
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
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
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
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
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.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,
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 -
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,
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,
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.
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
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
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?
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.
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
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
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
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
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
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)
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 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
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
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:
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 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
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
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
---
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
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
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 ---
1 - 100 of 139 matches
Mail list logo
