The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
On 26.08.2020 01:48, Stefano Stabellini wrote:
> On Tue, 25 Aug 2020, Jan Beulich wrote:
>> On 25.08.2020 11:31, Simon Leiner wrote:
>>> --- a/include/xen/arm/page.h
>>> +++ b/include/xen/arm/page.h
>>> @@ -76,7 +76,11 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
>>> #define bfn_to
flight 152822 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On Tue, 25 Aug 2020, Simon Leiner wrote:
> As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
> used with vmalloc'd addresses. This patch introduces a warning, when
> virt_to_gfn is used in this way.
>
> Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
> ---
>
On Tue, 25 Aug 2020, Simon Leiner wrote:
> On some architectures (like ARM), virt_to_gfn cannot be used for
> vmalloc'd memory because of its reliance on virt_to_phys. This patch
> introduces a check for vmalloc'd addresses and obtains the PFN using
> vmalloc_to_pfn in that case.
>
> Signed-off-by
On Tue, 25 Aug 2020, Jan Beulich wrote:
> On 25.08.2020 11:31, Simon Leiner wrote:
> > --- a/include/xen/arm/page.h
> > +++ b/include/xen/arm/page.h
> > @@ -76,7 +76,11 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
> > #define bfn_to_local_pfn(bfn) bfn_to_pfn(bfn)
> >
> > /*
On Tue, Aug 25, 2020 at 8:43 AM Jürgen Groß wrote:
>
> On 25.08.20 17:22, Thomas Gleixner wrote:
> > XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
> > XEN data pointer which contains XEN specific information.
> >
> > handler data is meant for interrupt handlers and not f
On Tue, Aug 25 2020 at 23:40, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 16:35, Bjorn Helgaas wrote:
>> On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
>>>
>>> Or did you just mean that those architectures should select
>>> CONFIG_I_WANT_THE CRUFT instead of opting out on the
flight 152793 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 152631
test-amd64-amd64-
On Tue, Aug 25, 2020 at 11:30:41PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:24, Bjorn Helgaas wrote:
> > On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> >> Rename it to x86_msi_prepare() and handle the allocation type setup
> >> depending on the device type.
> >
On Tue, Aug 25 2020 at 16:35, Bjorn Helgaas wrote:
> On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
>>
>> Or did you just mean that those architectures should select
>> CONFIG_I_WANT_THE CRUFT instead of opting out on the fully irq domain
>> based ones?
>
> Yes, that was my real
On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:07, Bjorn Helgaas wrote:
> >> + * The arch hooks to setup up msi irqs. Default functions are implemented
> >> + * as weak symbols so that they /can/ be overriden by architecture
> >> specific
> >> + * code
On Tue, Aug 25 2020 at 15:24, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
>> Rename it to x86_msi_prepare() and handle the allocation type setup
>> depending on the device type.
>
> I see what you're doing, but the subject reads a little strangely
Yes :(
On Tue, Aug 25 2020 at 15:07, Bjorn Helgaas wrote:
>> + * The arch hooks to setup up msi irqs. Default functions are implemented
>> + * as weak symbols so that they /can/ be overriden by architecture specific
>> + * code if needed.
>> + *
>> + * They can be replaced by stubs with warnings via
>> +
On Tue, Aug 25 2020 at 15:03, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 02:24:37AM +0200, Thomas Gleixner wrote:
>> Retrieve the PCI device from the msi descriptor instead of doing so at the
>> call sites.
>
> I'd like it *better* with "PCI/MSI: " in the subject (to match history
Duh, yes.
>
On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> Rename it to x86_msi_prepare() and handle the allocation type setup
> depending on the device type.
I see what you're doing, but the subject reads a little strangely
("pci_msi_prepare() handling non-PCI" stuff) since it doesn't men
s/Reducde/Reduce/ (in subject)
On Fri, Aug 21, 2020 at 02:24:41AM +0200, Thomas Gleixner wrote:
> Adding a function call before the first #ifdef in arch_pci_init() triggers
> a 'mixed declarations and code' warning if PCI_DIRECT is enabled.
>
> Use stub functions and move the #ifdeffery to the he
On Fri, Aug 21, 2020 at 02:24:45AM +0200, Thomas Gleixner wrote:
> Provide a helper function to check whether a PCI device is handled by a
> non-standard PCI/MSI domain. This will be used to exclude such devices
> which hang of a special bus, e.g. VMD, to be excluded from the irq domain
> override
On Fri, Aug 21, 2020 at 02:24:54AM +0200, Thomas Gleixner wrote:
> If an architecture does not require the MSI setup/teardown fallback
> functions, then allow them to be replaced by stub functions which emit a
> warning.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn Helgaas
> Cc: linux-...@vger
On Fri, Aug 21, 2020 at 02:24:37AM +0200, Thomas Gleixner wrote:
> Retrieve the PCI device from the msi descriptor instead of doing so at the
> call sites.
I'd like it *better* with "PCI/MSI: " in the subject (to match history
and other patches in this series) and "MSI" here in the commit log,
but
On Fri, Aug 21, 2020 at 02:24:44AM +0200, Thomas Gleixner wrote:
> Devices on the VMD bus use their own MSI irq domain, but it is not
> distinguishable from regular PCI/MSI irq domains. This is required
> to exclude VMD devices from getting the irq domain pointer set by
> interrupt remapping.
>
>
This will remove instance_size/class_size fields from TypeInfo
variables when the value is exactly the same as the one in the
parent class.
Generated by:
$ ./scripts/codeconverter/converter.py -i \
--pattern=RedundantTypeSizes $(git grep -l TypeInfo -- '*.[ch]')
Signed-off-by: Eduardo Habkos
Replace DECLARE_OBJ_CHECKERS with OBJECT_DECLARE_TYPE where the
typedefs can be safely removed.
Generated running:
$ ./scripts/codeconverter/converter.py -i \
--pattern=DeclareObjCheckers $(git grep -l '' -- '*.[ch]')
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
Changes
The typedef was used in the XENBACKEND_DEVICE macro, but it was
never defined. Define the typedef close to the type checking
macro.
Acked-by: Anthony PERARD
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3: none
Changes series v1 -> v2: new patch in series v
flight 152811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152811/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 152788 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
From: Julien Grall
Commit 858c0be8c2fa "xen/arm: Enable CPU Erratum 1165522 for Neoverse"
added a new erratum but forgot to update silicon-errata.txt.
Update the file accordingly to keep track of errata workaround in Xen.
Signed-off-by: Julien Grall
Cc: Bertrand Marquis
---
docs/misc/arm/sil
On 25/08/2020 15:29, Wei Chen wrote:
Hi Julien,
-Original Message-
From: Julien Grall
Sent: 2020年8月25日 19:18
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Andre Przywara ; Bertrand Marquis
; Penny Zheng ; Kaly
Xin ; nd
Subject: Re: [PATCH v3 2/2] xen/arm
On 24/08/2020 16:29, luckybreak051779 wrote:
Hi Julien
Hi,
Thanks for getting back to me.
On Mon, Aug 24, 2020 at 11:10 AM Julien Grall wrote:
Hi,
On 24/08/2020 15:23, luckybreak051779 wrote:
Xen Team:
I am running Xen 4.13.0 on a 32-bit ARM processor. In a domU driver I
use the dm
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
FP/SIMD or not. But currently, these 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 floating-point arithmetic, the
ID_AA64PFR0_EL1.FP/SIM
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the future,
Xen behaviors for value <= 0x1 can
On latest Arm Cortex-N1/A76/A75 cores, Xen guests will encouter random
crash when they have wordloads. It's because Xen will ignore FP/SIMD
registers in vCPU context switch (see patch#1 for more details).
This patch set fix guest random crash on these new cores, and throw
messages when Xen detects
On 25.08.20 17:22, Thomas Gleixner wrote:
XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
XEN data pointer which contains XEN specific information.
handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require hand
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index fd7b238b..d9bb2585 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2563,6 +2563,9 @@ sub target_var ($$) {
}
This was for distinguishing the old-style Xenolinux kernels from pvops
kernels.
We have not actually tested any non-pvops kernels for a very very long
time. Delete this now because the runvar is slightly in the way of
test host reuse.
(Sorry for the wide CC but it seems better to make sure anyon
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 61a99bc3..4151aa6c 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -693,7 +693,7 @@ sub plan_search () {
$onhost can be undef. Fixes this warning:
Use of uninitialized value $onhost in concatenation (.) or string at
Osstest/Executive.pm line 1293.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osste
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 4
1 file changed, 4 insertions(+)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 698437c0..8f7a1af0 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -1035,6 +1035,10 @@ s
No functional change.
Signed-off-by: Ian Jackson
---
sg-run-job | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index df3d08d0..3db05b34 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -30,12 +30,12 @@ proc per-host-prep {} {
per-host-ts .
This can happen, for example, if a badly broken flight has steps which
are STARTING and have NULL in the start time column, and is then
reported using sg-report-flight.
Signed-off-by: Ian Jackson
---
Osstest.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest.pm b/Osstest.pm
index b2b
Combine these two functions. Rename them to a name which doesn't
mention "kernkind".
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 3 +--
Osstest/TestSupport.pm | 11 ---
ts-debian-fixup| 3 +--
3 files changed, 6 insertions(+), 11 deletions(-)
Now we have things like "sock55599edaf050" where previously we had
something like "sock142". So the output is misaligned.
Bump the sizes. And with these longer names, when showing the front
of the queue only print the full first entry and the start of the next
one.
Signed-off-by: Ian Jackson
-
Signed-off-by: Ian Jackson
---
README.planner | 60 ++
1 file changed, 60 insertions(+)
diff --git a/README.planner b/README.planner
index c33aae11..f134d716 100644
--- a/README.planner
+++ b/README.planner
@@ -203,6 +203,66 @@ that shared systems
We move this earlier. This is OK because it depends only on the
console runvar (inside the sub; this is set by target_kernkind_check),
$ho and $gho (which are set by this point); and $mountpoint$ (which is
set by access().
No functional change.
Signed-off-by: Ian Jackson
---
ts-debian-fixup |
This small pre-series contains cleanups arising from my test host
reuse work. The final patch is a feature removal.
Ian Jackson (12):
ms-queuedaemon: Update for newer Tcl's socket channel ids
Executive.pm planner: fix typo
README.planner: Document magic job hostflags
sg-run-job: Minor whi
This is OK because nothing in access() looks at the rootdev or console
runvars, which are what target_kernkind_check sets.
No functional change other than perhaps to log output.
Signed-off-by: Ian Jackson
---
ts-debian-fixup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts
flight 152779 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152779/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt 18 guest-start/debian.repeat fail in 152750 pass in
152779
test-amd64-i386-xl-qemut-de
Please put "xen: " in the subject line.
On Tue, Aug 25, 2020 at 02:31:12PM +0200, Jan Beulich wrote:
> Besides the one use that there is in the function (of the value
> calculated at function entry), there are two more places where the
> redundant page-to-address conversion can be avoided.
>
> Si
On Tue, Aug 25 2020 at 14:20, Christoph Hellwig wrote:
> On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote:
>> From: Thomas Gleixner
>>
>> followed by an empty new line before the actual changelog text
>> starts. That way the attribution of the patch when applying it will be
>> corr
XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
XEN data pointer which contains XEN specific information.
handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require handler data to store internal
per interrupt inf
On Tue, Aug 25, 2020 at 10:37:09AM +, George Dunlap wrote:
>
>
> > On Aug 25, 2020, at 7:47 AM, Jan Beulich wrote:
> >
> > On 24.08.2020 16:58, Nick Rosbrook wrote:
> >> My understanding was that you were going to use move-if-changed to fix
> >> this for now (it seemed everyone agreed this
I have no objections. For the OCaml part in particular I previously said that I
believe that it would benefit from either be maintained outside the tree (which
requires a clean interface) or moving it to use Dune for its build (triggered
by the current make build). Any cleanup that is helping h
> On Aug 25, 2020, at 7:47 AM, Jan Beulich wrote:
>
> On 24.08.2020 16:58, Nick Rosbrook wrote:
>> My understanding was that you were going to use move-if-changed to fix
>> this for now (it seemed everyone agreed this was the quickest short-term
>> fix).
>
> A technical and a non-technical re
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2020年8月25日 19:18
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Andre Przywara ; Bertrand Marquis
> ; Penny Zheng ; Kaly
> Xin ; nd
> Subject: Re: [PATCH v3 2/2] xen/arm: Throw messages for unkn
On 25.08.20 10:58, Thomas Gleixner wrote:
On Mon, Aug 24 2020 at 20:14, Stefano Stabellini wrote:
On Fri, 21 Aug 2020, Thomas Gleixner wrote:
are accessors to handler_data. Am I missing something?
I think Juergen's suggestion was to use function pointers as accessors.
The underlying problem i
On 07.08.2020 12:12, Jan Beulich wrote:
> On 06.08.2020 21:16, Andrew Cooper wrote:
>> On 06/08/2020 10:28, Jan Beulich wrote:
>>> Note that opt_pv32's declaration / #define need to be moved due to other
>>> header dependencies; in particular can asm-x86/mm.h not include
>>> asm-x86/pv/domain.h.
>>
On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> followed by an empty new line before the actual changelog text
> starts. That way the attribution of the patch when applying it will be
> correct.
The way he sent it attribution will be correct as he man
On 20/08/2020 12:57, Simon Leiner wrote:
Hi Julien,
Hi Simon,
On 20.08.20 13:17, Julien Grall wrote:
There is a lot of interest to get Virtio working on Xen at the moment.
Is this going to be a new transport layer for Virtio?
It is designed that way, yes. The current implementation (b
Hi Jan,
On 25/08/2020 13:31, Jan Beulich wrote:
Besides the one use that there is in the function (of the value
calculated at function entry), there are two more places where the
redundant page-to-address conversion can be avoided.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
> On 25 Aug 2020, at 13:51, Jürgen Groß wrote:
>
> On 25.08.20 14:44, Bertrand Marquis wrote:
>>> On 25 Aug 2020, at 13:37, Jürgen Groß wrote:
>>>
>>> On 25.08.20 14:20, Bertrand Marquis wrote:
> On 25 Aug 2020, at 12:22, Jürgen Groß wrote:
>
> On 25.08.20 13:16, Bertrand Marqui
On 25.08.20 14:08, Jan Beulich wrote:
On 25.08.2020 11:49, Jürgen Groß wrote:
On 25.08.20 10:48, Jan Beulich wrote:
On 25.08.2020 10:08, Jürgen Groß wrote:
Correct me if I'm wrong, but assuming my suggested changes being made,
wouldn't a .config file setup once with CET enabled (and I assume y
On 25.08.20 14:44, Bertrand Marquis wrote:
On 25 Aug 2020, at 13:37, Jürgen Groß wrote:
On 25.08.20 14:20, Bertrand Marquis wrote:
On 25 Aug 2020, at 12:22, Jürgen Groß wrote:
On 25.08.20 13:16, Bertrand Marquis wrote:
On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
On 25.08.20 12:17, Ber
On 24.08.2020 19:32, Andrew Cooper wrote:
> On 24/08/2020 12:58, Jan Beulich wrote:
>> With changes done over time and as far as linking goes, the only special
>> things about building with EFI support enabled are
>> - the need for the dummy relocations object for xen.gz uniformly in all
>> build
> On 25 Aug 2020, at 13:37, Jürgen Groß wrote:
>
> On 25.08.20 14:20, Bertrand Marquis wrote:
>>> On 25 Aug 2020, at 12:22, Jürgen Groß wrote:
>>>
>>> On 25.08.20 13:16, Bertrand Marquis wrote:
> On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
>
> On 25.08.20 12:17, Bertrand Marqui
On 25.08.20 14:20, Bertrand Marquis wrote:
On 25 Aug 2020, at 12:22, Jürgen Groß wrote:
On 25.08.20 13:16, Bertrand Marquis wrote:
On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
On 25.08.20 12:17, Bertrand Marquis wrote:
On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
On 25.08.20 10:48, Jan
Besides the one use that there is in the function (of the value
calculated at function entry), there are two more places where the
redundant page-to-address conversion can be avoided.
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1380,7 +1380,7 @@ sta
> On 25 Aug 2020, at 12:22, Jürgen Groß wrote:
>
> On 25.08.20 13:16, Bertrand Marquis wrote:
>>> On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
>>>
>>> On 25.08.20 12:17, Bertrand Marquis wrote:
> On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
>
> On 25.08.20 10:48, Jan Beulich wro
On 25.08.2020 11:31, Simon Leiner wrote:
> --- a/include/xen/arm/page.h
> +++ b/include/xen/arm/page.h
> @@ -76,7 +76,11 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
> #define bfn_to_local_pfn(bfn)bfn_to_pfn(bfn)
>
> /* VIRT <-> GUEST conversion */
> -#define virt_to_gfn
flight 152786 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152786/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 78ab44cb96808bd3ff0edf312599f94a6a92172a
baseline version:
ovmf ad40eb4e6c9d5576cca24
On 25.08.2020 11:49, Jürgen Groß wrote:
> On 25.08.20 10:48, Jan Beulich wrote:
>> On 25.08.2020 10:08, Jürgen Groß wrote:
>>> Correct me if I'm wrong, but assuming my suggested changes being made,
>>> wouldn't a .config file setup once with CET enabled (and I assume you'd
>>> try to enable CET on
On 25.08.20 13:16, Marek Marczykowski-Górecki wrote:
On Sun, Aug 23, 2020 at 11:35:07AM +0200, Juergen Gross wrote:
Today tools/libxc needs to be built after tools/libs as libxenctrl is
depending on some libraries in tools/libs. This in turn blocks moving
other libraries depending on libxenctrl
On 25.08.20 13:16, Bertrand Marquis wrote:
On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
On 25.08.20 12:17, Bertrand Marquis wrote:
On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
On 25.08.20 10:48, Jan Beulich wrote:
On 25.08.2020 10:08, Jürgen Groß wrote:
On 25.08.20 09:48, Jan Beulich wr
Hi,
On 25/08/2020 11:08, Wei Chen wrote:
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the
On Sun, Aug 23, 2020 at 11:35:07AM +0200, Juergen Gross wrote:
> Today tools/libxc needs to be built after tools/libs as libxenctrl is
> depending on some libraries in tools/libs. This in turn blocks moving
> other libraries depending on libxenctrl below tools/libs.
>
> So carve out libxenctrl fro
> On 25 Aug 2020, at 12:06, Jürgen Groß wrote:
>
> On 25.08.20 12:17, Bertrand Marquis wrote:
>>> On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
>>>
>>> On 25.08.20 10:48, Jan Beulich wrote:
On 25.08.2020 10:08, Jürgen Groß wrote:
> On 25.08.20 09:48, Jan Beulich wrote:
>> On 25.08
On Wed, Aug 19, 2020 at 08:12:04PM -0400, Eduardo Habkost wrote:
> The typedef was used in the XENBACKEND_DEVICE macro, but it was
> never defined. Define the typedef close to the type checking
> macro.
>
> Signed-off-by: Eduardo Habkost
> ---
> Changes series v1 -> v2: new patch in series v2
>
On Sun, Aug 23, 2020 at 11:35:03AM +0200, Juergen Gross wrote:
> For being able to disentangle lixenctrl and libxenguest headers
> xc_dom.h will need to be public. Prepare that by renaming xc_dom.h
> to xenctrl_dom.h.
>
> Signed-off-by: Juergen Gross
Python changes:
Acked-by: Marek Marczykowski-
On Sun, Aug 23, 2020 at 11:34:52AM +0200, Juergen Gross wrote:
> There is not a single wrapper for a libxenguest function defined.
> So drop libxenguest from tools/python/setup.py.
>
> Signed-off-by: Juergen Gross
Acked-by: Marek Marczykowski-Górecki
> ---
> tools/python/setup.py | 4 ++--
>
On 25.08.20 12:17, Bertrand Marquis wrote:
On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
On 25.08.20 10:48, Jan Beulich wrote:
On 25.08.2020 10:08, Jürgen Groß wrote:
On 25.08.20 09:48, Jan Beulich wrote:
On 25.08.2020 09:43, Jürgen Groß wrote:
On 25.08.20 09:34, Jan Beulich wrote:
On 25
On 10.08.2020 19:09, Andrew Cooper wrote:
> On 06/08/2020 10:06, Jan Beulich wrote:
>> Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
>> free ebmalloc area at all") was put in place: Make xen_in_range() aware
>> of the freed range. This is in particular relevant for EFI-enab
> On 25 Aug 2020, at 04:02, Wei Chen wrote:
>
> Hi Julien, Bertrand,
>
>> -Original Message-
>> From: Julien Grall
>> Sent: 2020年8月25日 1:23
>> To: Bertrand Marquis
>> Cc: Wei Chen ; Xen-devel > de...@lists.xenproject.org>; sstabell...@kernel.org; Andre Przywara
>> ; Penny Zheng ; Kal
> On 25 Aug 2020, at 10:49, Jürgen Groß wrote:
>
> On 25.08.20 10:48, Jan Beulich wrote:
>> On 25.08.2020 10:08, Jürgen Groß wrote:
>>> On 25.08.20 09:48, Jan Beulich wrote:
On 25.08.2020 09:43, Jürgen Groß wrote:
> On 25.08.20 09:34, Jan Beulich wrote:
>> On 25.08.2020 09:12, Jürg
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the future,
Xen behaviors for value <= 0x1 can
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
FP/SIMD or not. But currently, these 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 floating-point arithmetic, the
ID_AA64PFR0_EL1.FP/SIM
On latest Arm Cortex-N1/A76/A75 cores, Xen guests will encouter random
crash when they have wordloads. It's because Xen will ignore FP/SIMD
registers in vCPU context switch (see patch#1 for more details).
This patch set fix guest random crash on these new cores, and throw
messages when Xen detects
On Tue, Aug 25 2020 at 06:21, Jürgen Groß wrote:
> On 24.08.20 23:21, Thomas Gleixner wrote:
>> I still think it does the right thing depending on the place it is
>> called from, but even if so, it's completely unreadable gunk. I'll fix
>> that proper.
>
> The main issue is that xen_initial_domain(
On 25.08.20 10:48, Jan Beulich wrote:
On 25.08.2020 10:08, Jürgen Groß wrote:
On 25.08.20 09:48, Jan Beulich wrote:
On 25.08.2020 09:43, Jürgen Groß wrote:
On 25.08.20 09:34, Jan Beulich wrote:
On 25.08.2020 09:12, Jürgen Groß wrote:
I think both problems can be solved at the same time via t
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
---
drivers/xen/xenbus/xenbus_client
As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
used with vmalloc'd addresses. This patch introduces a warning, when
virt_to_gfn is used in this way.
Signed-off-by: Simon Leiner
---
include/xen/arm/page.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --
On Mon, Aug 24 2020 at 20:14, Stefano Stabellini wrote:
> On Fri, 21 Aug 2020, Thomas Gleixner wrote:
>> are accessors to handler_data. Am I missing something?
> I think Juergen's suggestion was to use function pointers as accessors.
>
> The underlying problem is that both Xen and GPIO want to use
flight 152771 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 152631
test-amd64-amd64-
On 25.08.2020 10:08, Jürgen Groß wrote:
> On 25.08.20 09:48, Jan Beulich wrote:
>> On 25.08.2020 09:43, Jürgen Groß wrote:
>>> On 25.08.20 09:34, Jan Beulich wrote:
On 25.08.2020 09:12, Jürgen Groß wrote:
> I think both problems can be solved at the same time via the following
> approa
On 12.08.2020 14:47, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -375,6 +375,50 @@ static const struct hvm_mmio_ops vioapic_mmio_ops = {
> .write = vioapic_write
> };
>
> +static void eoi_callback(struct vcpu *v, unsigned int vector, voi
On 25.08.20 09:48, Jan Beulich wrote:
On 25.08.2020 09:43, Jürgen Groß wrote:
On 25.08.20 09:34, Jan Beulich wrote:
On 25.08.2020 09:12, Jürgen Groß wrote:
I think both problems can be solved at the same time via the following
approach:
- collect the data which is reflected in today's CONFIG_
On Mon, Aug 24 2020 at 08:21, Jürgen Groß wrote:
> On 21.08.20 02:24, Thomas Gleixner wrote:
>
> Looking into https://www.kernel.org/doc/Documentation/IRQ-domain.txt (is
> this still valid?)
It's halfways correct. Emphasis on halfways.
> I believe Xen should be able to use the "No Map" approach,
On 25.08.2020 09:43, Jürgen Groß wrote:
> On 25.08.20 09:34, Jan Beulich wrote:
>> On 25.08.2020 09:12, Jürgen Groß wrote:
>>> I think both problems can be solved at the same time via the following
>>> approach:
>>>
>>> - collect the data which is reflected in today's CONFIG_ variables in a
>>>
On 25.08.20 09:43, Jürgen Groß wrote:
On 25.08.20 09:34, Jan Beulich wrote:
On 25.08.2020 09:12, Jürgen Groß wrote:
On 25.08.20 08:31, Jan Beulich wrote:
1) Does it make sense for tool chain capabilities to be recorded?
2) Does the recording actually work reliably?
As to 1), I'm personally o
On 25.08.20 09:34, Jan Beulich wrote:
On 25.08.2020 09:12, Jürgen Groß wrote:
On 25.08.20 08:31, Jan Beulich wrote:
1) Does it make sense for tool chain capabilities to be recorded?
2) Does the recording actually work reliably?
As to 1), I'm personally of the opinion that the original model
w
On 24.08.2020 20:15, Andrew Cooper wrote:
> I'm pretty sure the mfn_to_gmfn() stub is bogus before and after this change.
> The two uses in common code are getdomaininfo and in memory_exchange(), which
> result in junk.
It's been a long time back that I think I did suggest to restrict
memory_excha
1 - 100 of 104 matches
Mail list logo
