On Mon, Oct 26, 2020 at 05:02:14PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> If the
- 23 paź, 2020 o 6:47, Jürgen Groß jgr...@suse.com napisał(a):
> On 23.10.20 00:59, Michał Leszczyński wrote:
>> Hello,
>>
>> when using DRAKVUF against a Windows 7 x64 DomU, the whole machine hangs
>> after a
>> few minutes.
>>
>> The chance for a hang seems to be correlated with number
On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> On 26/10/2020 16:03, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> >> On 24/10/2020 06:35, Elliott Mitchell wrote:
> >>> ACPI has a distinct
> >>> means of specifying a limited DMA-width;
flight 156258 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156258/
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
On Mon, 26 Oct 2020, Rahul Singh wrote:
> passthrough/pci.c file is common for all architecture, but there is x86
> sepcific code in this file.
^ specific
> Move x86 specific code to the x86 directory to avoid compilation error
> for other architecture.
>
> No functional change.
>
>
On Mon, 26 Oct 2020, Rahul Singh wrote:
> This patch series is preparatory work to make PCI passthrough code non-x86
> specific.
Do you have a simple patch I could use to test the compilation on ARM?
Even just a hack to help me review the series?
Right now I can only test that the compilation on
On Mon, 26 Oct 2020, Rahul Singh wrote:
> PCI ATS functionality is not enabled and tested for ARM architecture
> but it is enabled for x86 and referenced in common passthrough/pci.c
> code.
>
> Therefore introducing the new flag to enable the ATS functionality for
> x86 only to avoid issues for
On Mon, 26 Oct 2020, Rahul Singh wrote:
> ARM platforms does not support ns16550 PCI support. When CONFIG_HAS_PCI
^ do
> is enabled for ARM a compilation error is observed.
>
> Fixed compilation error after introducing new kconfig option
> CONFIG_HAS_NS16550_PCI for x86 platforms
On 27/10/2020 17:41, Olaf Hering wrote:
> Andrew,
>
> with commit 93c2ff78adcadbe0f8bda57eeb30b1414c966324 a new function
> process_page_data was added. While filling the mfns array for
> xenforeignmemory_map, the individual pfn types[] are checked in a different
> way than the checking of the
On Mon, 26 Oct 2020, Bertrand Marquis wrote:
> When a Cortex A57 processor is affected by CPU errata 832075, a guest
> not implementing the workaround for it could deadlock the system.
> Add a warning during boot informing the user that only trusted guests
> should be executed on the system.
> An
On Mon, 26 Oct 2020, Bertrand Marquis wrote:
> Define a new Unsecure taint type to be used to signal a system tainted
> due to an unsecure configuration or hardware feature/errata.
>
> Signed-off-by: Bertrand Marquis
Reviewed-by: Stefano Stabellini
> ---
> xen/common/kernel.c | 4 +++-
>
On Mon, 26 Oct 2020, Bertrand Marquis wrote:
> Replace usage of warning_add by printk_once with a prefix and
> suffix for errata related warnings.
>
> This prevents the need for the assert which is not secure enough to
> protect this print against wrong usage.
>
> Signed-off-by: Bertrand
flight 156260 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156260/
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
On Tue, 27 Oct 2020, Konrad Rzeszutek Wilk wrote:
> > As the person who first found this and then confirmed this fixes a bug:
> >
> > Tested-by: Elliott Mitchell
>
> Thank you!!
>
> I changed the title and added the various tags and will put it in
> linux-next later this week.
Looks fine,
flight 156257 qemu-mainline real [real]
flight 156266 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156257/
http://logs.test-lab.xenproject.org/osstest/logs/156266/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 27/10/2020 15:24, Jan Beulich wrote:
> On 26.10.2020 14:50, Andrew Cooper wrote:
>> The format of the Host State Area is, and has always been, a VMCB. It is
>> explicitly safe to put the host VMSAVE data in.
> Nit: The PM calls this "Host Save Area" or "Host State Save Area"
> afaics.
>
> I
> As the person who first found this and then confirmed this fixes a bug:
>
> Tested-by: Elliott Mitchell
Thank you!!
I changed the title and added the various tags and will put it in
linux-next later this week.
>From a1eb2768bf5954d25aa0f0136b38f0aa5d92d984 Mon Sep 17 00:00:00 2001
From:
Le 10/27/20 à 10:22 AM, Dario Faggioli a écrit :
On Tue, 2020-10-27 at 06:58 +0100, Jürgen Groß wrote:
On 26.10.20 17:31, Dario Faggioli wrote:
Or did you have something completely different in mind, and I'm
missing
it?
No, I think you are right. I mixed that up with __context_switch()
Le 10/27/20 à 4:42 PM, Frédéric Pierret a écrit :
Le 10/27/20 à 10:22 AM, Dario Faggioli a écrit :
On Tue, 2020-10-27 at 06:58 +0100, Jürgen Groß wrote:
On 26.10.20 17:31, Dario Faggioli wrote:
Or did you have something completely different in mind, and I'm
missing
it?
No, I think you
Le 10/27/20 à 10:22 AM, Dario Faggioli a écrit :
On Tue, 2020-10-27 at 06:58 +0100, Jürgen Groß wrote:
On 26.10.20 17:31, Dario Faggioli wrote:
Or did you have something completely different in mind, and I'm
missing
it?
No, I think you are right. I mixed that up with __context_switch()
flight 156254 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156254/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine 4 memdisk-try-append fail pass in 156248
test-amd64-amd64-pygrub 21
Hi Julien,
> On 27 Oct 2020, at 14:37, Julien Grall wrote:
>
>
>
> On 27/10/2020 14:19, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 26 Oct 2020, at 19:05, Julien Grall wrote:
>>>
>>> On 26/10/2020 12:10, Ash Wilding wrote:
Hi,
>>>
>>> Hi Ash,
>>>
> 1.
On 10/27/20 7:18 PM, Jan Beulich wrote:
> On 27.10.2020 16:52, Oleksandr Andrushchenko wrote:
>> On 10/27/20 2:55 PM, Roger Pau Monné wrote:
>>> On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
5. An alternative route for 3-4 could be to store that data in
On Tue, 27 Oct 2020, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 26, 2020 at 05:02:14PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> > allocate a buffer for the swiotlb. It does so by calling
> >
> >
Andrew,
with commit 93c2ff78adcadbe0f8bda57eeb30b1414c966324 a new function
process_page_data was added. While filling the mfns array for
xenforeignmemory_map, the individual pfn types[] are checked in a different way
than the checking of the result of the mapping attempt.
Is there a special
On 27.10.2020 16:52, Oleksandr Andrushchenko wrote:
> On 10/27/20 2:55 PM, Roger Pau Monné wrote:
>> On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
>>> 5. An alternative route for 3-4 could be to store that data in XenStore,
>>> e.g.
>>> MMIOs, IRQ, bind sysfs
On Tue, 27 Oct 2020 10:22:42 +0100 Dario Faggioli
wrote
On Tue, 2020-10-27 at 06:58 +0100, Jürgen Groß wrote:
> On 26.10.20 17:31, Dario Faggioli wrote:
> >
> > Or did you have something completely different in mind, and I'm
> > missing
> > it?
>
> No, I think you are right.
Hello, Roger!
On 10/27/20 2:55 PM, Roger Pau Monné wrote:
> On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
>> Hello, all!
>>
>> While working on PCI passthrough on ARM (partial RFC was published by ARM
>> earlier this year) I tried to implement some related changes in
On 26.10.2020 14:50, Andrew Cooper wrote:
> The format of the Host State Area is, and has always been, a VMCB. It is
> explicitly safe to put the host VMSAVE data in.
Nit: The PM calls this "Host Save Area" or "Host State Save Area"
afaics.
I recall us discussing this option in the past, and
On 27.10.2020 15:10, Andrew Cooper wrote:
> With MMU_UPDATE, a PV guest can make changes to higher level pagetables. This
> is safe from Xen's point of view (as the update only affects guest mappings),
> and the guest is required to flush (if necessary) after making updates.
>
> However, Xen's
On 27/10/2020 14:19, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 26 Oct 2020, at 19:05, Julien Grall wrote:
On 26/10/2020 12:10, Ash Wilding wrote:
Hi,
Hi Ash,
1. atomic_set_release
2. atomic_fetch_andnot_relaxed
3. atomic_cond_read_relaxed
4. atomic_long_cond_read_relaxed
On 27.10.2020 15:10, Andrew Cooper wrote:
> c/s 9d1d31ad9498 "x86: slightly reduce Meltdown band-aid overhead" removed the
> use of Global TLB flushes on the Xen entry path, but added a FLUSH_TLB_GLOBAL
> to the L4 path in do_mmu_update().
>
> However, this was unnecessary.
>
> The L4 resync
Hi Julien,
> On 26 Oct 2020, at 19:05, Julien Grall wrote:
>
> On 26/10/2020 12:10, Ash Wilding wrote:
>> Hi,
>
> Hi Ash,
>
>>> 1. atomic_set_release
>>> 2. atomic_fetch_andnot_relaxed
>>> 3. atomic_cond_read_relaxed
>>> 4. atomic_long_cond_read_relaxed
>>> 5. atomic_long_xor
>>> 6.
Dear all,
We are pleased to announce the release of MirageOS 3.9.0.
Our last release announcement was for [MirageOS
3.6.0](https://mirage.io/blog/announcing-mirage-36-release), so we will
also cover changes since 3.7.x and 3.8.x in this announcement.
New features:
- The Xen backend has been
Alternative XSA-286 fix, with far less of a performance hit.
v3:
* Split into two patches, to try and make the TLB flushing in do_mmu_update()
a tractable problem to solve.
Andrew Cooper (2):
x86/pv: Drop FLUSH_TLB_GLOBAL in do_mmu_update() for XPTI
x86/pv: Flush TLB in response to
With MMU_UPDATE, a PV guest can make changes to higher level pagetables. This
is safe from Xen's point of view (as the update only affects guest mappings),
and the guest is required to flush (if necessary) after making updates.
However, Xen's use of linear pagetables (UPDATE_VA_MAPPING,
c/s 9d1d31ad9498 "x86: slightly reduce Meltdown band-aid overhead" removed the
use of Global TLB flushes on the Xen entry path, but added a FLUSH_TLB_GLOBAL
to the L4 path in do_mmu_update().
However, this was unnecessary.
The L4 resync will pick up any new mappings created by the L4 change.
Signed-off-by: Ian Jackson
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README b/README
index 1703e076..ef6c4e60 100644
--- a/README
+++ b/README
@@ -655,7 +655,7 @@ HostProp__PowerILOM
unsupported Fails whenever a power operation is needed
We are going to make this script control PDUs other than APC ones.
No overall functional change for internal callers. Anyone out-of-tree
using this script will need to change the name of the program they run.
Signed-off-by: Ian Jackson
---
Osstest/PDU/msw.pm | 2 +-
README | 2
We have taken delivery of two Servertech PDUs which do
(near-)zero-crossing switching. We hope these will not suffer from
the relays welding shut like our APC PDUs do.
We will control these PDUs via SNMP, as we do for the APC PDUs, but
each PDU manufacturer uses their own SNMP range, so
Values from Sentry4.mib, from
https://www.servertech.com/support/sentry-mib-oid-tree-downloads
Useful runes used when developing and testing, with "Sentry.mib" from
the Servertech zipfile renamed to "mibs/Sentry4-MIB":
snmpwalk -On -m Sentry4-MIB -M +:mibs/ -Ci -v 2c -c private pdu1
Retain the old name for compatibility with existing configuration.
No change other than to messages.
Signed-off-by: Ian Jackson
---
Osstest/PDU/msw.pm | 14 +-
Osstest/PDU/snmp.pm | 39 +++
README | 9 ++---
3 files changed, 46
Do not hardcoode .3 and .4 in the main logic.
No functional change.
Signed-off-by: Ian Jackson
---
pdu-snmp | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/pdu-snmp b/pdu-snmp
index 581a60b0..a4918f53 100755
--- a/pdu-snmp
+++ b/pdu-snmp
@@ -27,8 +27,11 @@ use
This makes it easier to see waht is going on and to add new model(s).
No functional change.
Signed-off-by: Ian Jackson
---
pdu-snmp | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/pdu-snmp b/pdu-snmp
index a4918f53..74244145 100755
---
sleep takes only an integer. We have to use select to sleep for
fractions of a second.
Signed-off-by: Ian Jackson
---
pdu-snmp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pdu-snmp b/pdu-snmp
index 61380766..79d22e1f 100755
--- a/pdu-snmp
+++ b/pdu-snmp
@@ -172,7 +172,7
On Mon, Oct 26, 2020 at 05:02:14PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> If the
On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
> Hello, all!
>
> While working on PCI passthrough on ARM (partial RFC was published by ARM
> earlier this year) I tried to implement some related changes in the toolstack.
> One of the obstacles for ARM is PCI backend’s
flight 156255 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156255/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eb520b93d279e901a593c57e30649fb08f4290c5
baseline version:
ovmf
flight 156251 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156251/
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
$(DSDT_FILES-y) depends on the recursive make to have run in libacpi/
such that the file(s) itself/themselves were generated before
compilation gets attempted. The same, however, is also necessary for
generated headers, before source files including them would get
attempted to be compiled.
The
Hi Julien,
> Would Arm be willing to add support for LSE before merging the
> SMMUv3?
(( Taking my Arm hat off for a second and speaking independently... ))
I've been toying with doing this in my own personal time but unsure how
long it would take (unable to commit much time on it right now).
On 27.10.2020 11:57, Andrew Cooper wrote:
> On 27/10/2020 10:37, Jan Beulich wrote:
>> On 27.10.2020 11:27, Olaf Hering wrote:
>>> Am Tue, 27 Oct 2020 11:16:04 +0100
>>> schrieb Jan Beulich :
>>>
This pattern is used when a rule consists of multiple commands
having their output appended
Hi George,
On 27/10/2020 10:58, George Dunlap wrote:
It's only called from another __init function.
Signed-off-by: George Dunlap
Acked-by: Julien Grall
Cheers,
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Roger Pau Monne
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/mm.c
It's only called from another __init function.
Signed-off-by: George Dunlap
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Roger Pau Monne
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/mm.c | 2 +-
xen/arch/x86/mm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On 27/10/2020 10:58, George Dunlap wrote:
> It's only called from another __init function.
>
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
On 27/10/2020 10:37, Jan Beulich wrote:
> On 27.10.2020 11:27, Olaf Hering wrote:
>> Am Tue, 27 Oct 2020 11:16:04 +0100
>> schrieb Jan Beulich :
>>
>>> This pattern is used when a rule consists of multiple commands
>>> having their output appended to one another's.
>> My understanding is: a rule
Am Tue, 27 Oct 2020 11:38:04 +0100
schrieb Jan Beulich :
> I guess I'll make a patch then.
Thanks. I briefly looked at the code and it is not obvious how it would need to
look like.
Olaf
pgphFNbYHfwgk.pgp
Description: Digitale Signatur von OpenPGP
On 27.10.2020 11:30, Olaf Hering wrote:
> Am Tue, 27 Oct 2020 11:25:17 +0100
> schrieb Jan Beulich :
>
>> In this context it then is relevant in which context you see the failure -
>> firmware/hvmloader/ or libs/light/ ?
>
> I do not have the log anymore to check this detail.
>From looking at
On 27.10.2020 11:27, Olaf Hering wrote:
> Am Tue, 27 Oct 2020 11:16:04 +0100
> schrieb Jan Beulich :
>
>> This pattern is used when a rule consists of multiple commands
>> having their output appended to one another's.
>
> My understanding is: a rule is satisfied as soon as the file exists.
No
Am Tue, 27 Oct 2020 11:25:17 +0100
schrieb Jan Beulich :
> In this context it then is relevant in which context you see the failure -
> firmware/hvmloader/ or libs/light/ ?
I do not have the log anymore to check this detail.
Olaf
pgpnVV_Iyo1_o.pgp
Description: Digitale Signatur von OpenPGP
Am Tue, 27 Oct 2020 11:16:04 +0100
schrieb Jan Beulich :
> This pattern is used when a rule consists of multiple commands
> having their output appended to one another's.
My understanding is: a rule is satisfied as soon as the file exists. In this
case once the invoked shell opens the file for
On 27.10.2020 11:18, Jan Beulich wrote:
> On 27.10.2020 10:45, Olaf Hering wrote:
>> Every once in a while build.c fails to compile because ssdt_s3.h does not
>> exist. The 'sed' command which creates the file appears a few lines down in
>> the build log.
>>
>> I'm not familiar with make. I
On 27.10.2020 10:45, Olaf Hering wrote:
> Every once in a while build.c fails to compile because ssdt_s3.h does not
> exist. The 'sed' command which creates the file appears a few lines down in
> the build log.
>
> I'm not familiar with make. I wonder if "build.o" should depend on "$(H_SRC)"
>
On 26.10.2020 21:41, Olaf Hering wrote:
> Use a temporay file, and move it in place once done.
> The same pattern exists already for other dependencies.
This pattern is used when a rule consists of multiple commands
having their output appended to one another's. This isn't the
case here, so I'm
Hello, all!
While working on PCI passthrough on ARM (partial RFC was published by ARM
earlier this year) I tried to implement some related changes in the toolstack.
One of the obstacles for ARM is PCI backend’s related code presence: ARM is
going to fully emulate an ECAM host bridge in Xen, so no
Every once in a while build.c fails to compile because ssdt_s3.h does not
exist. The 'sed' command which creates the file appears a few lines down in the
build log.
I'm not familiar with make. I wonder if "build.o" should depend on "$(H_SRC)"
instead of the expanded list of generated headers.
flight 156250 qemu-mainline real [real]
flight 156256 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156250/
http://logs.test-lab.xenproject.org/osstest/logs/156256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Tue, 2020-10-27 at 06:58 +0100, Jürgen Groß wrote:
> On 26.10.20 17:31, Dario Faggioli wrote:
> >
> > Or did you have something completely different in mind, and I'm
> > missing
> > it?
>
> No, I think you are right. I mixed that up with __context_switch()
> not
> being called.
>
Right.
>
flight 156252 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156252/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a3212009d95bbcba7d08076aba2eee51eb1f8e7c
baseline version:
ovmf
Looks good for now:
Reviewed-by: Christoph Hellwig
But we really need to clean up the mess with all these magic variables
eventually.
Hello, Dan!
On 10/21/20 1:50 PM, Dan Carpenter wrote:
> Hello Oleksandr Andrushchenko,
>
> The patch 58f9d806d16a: "ALSA: xen-front: Use Xen common shared
> buffer implementation" from Nov 30, 2018, leads to the following
> static checker warning:
>
> sound/xen/xen_snd_front_alsa.c:495
flight 156253 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156253/
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
flight 156248 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156248/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 156228
test-armhf-armhf-libvirt 16
73 matches
Mail list logo
