flight 173262 qemu-mainline real [real]
flight 173265 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173262/
http://logs.test-lab.xenproject.org/osstest/logs/173265/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Bernhard Beschow writes:
> Am 20. September 2022 11:36:47 UTC schrieb Markus Armbruster
> :
>>Alistair Francis writes:
>>
>>> On Tue, Sep 20, 2022 at 9:18 AM Bernhard Beschow wrote:
SiFiveEState inherits from SysBusDevice while it's TypeInfo claims it to
inherit from
From: Minghao Chi
use kstrdup instead of open-coding it.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
drivers/net/xen-netback/xenbus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index
[AMD Official Use Only - General]
Hi Paul and AFAIK:
Thanks for your help.
When could we see this patch on the master branch?
Our project urgently needs this solution.
Thanks!
Ruili
-Original Message-
From: Paul Durrant
Subject: RE: [PATCH] hw/xen: set pci Atomic Ops requests for
flight 173261 linux-linus real [real]
flight 173263 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173261/
http://logs.test-lab.xenproject.org/osstest/logs/173263/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 9/20/22 3:21 PM, Kees Cook wrote:
After expanding bounds checking to use __builtin_dynamic_object_size(),
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct
Am 20. September 2022 11:36:47 UTC schrieb Markus Armbruster
:
>Alistair Francis writes:
>
>> On Tue, Sep 20, 2022 at 9:18 AM Bernhard Beschow wrote:
>>>
>>> SiFiveEState inherits from SysBusDevice while it's TypeInfo claims it to
>>> inherit from TYPE_MACHINE. This is an inconsistency which
Am 20. September 2022 09:02:41 UTC schrieb BALATON Zoltan :
>
>
>On Tue, 20 Sep 2022, Philippe Mathieu-Daudé via wrote:
>
>> On 20/9/22 01:17, Bernhard Beschow wrote:
>>> The functions just access a global pointer and perform some pointer
>>> arithmetic on top. Allow the compiler to see through
Am 20. September 2022 08:50:01 UTC schrieb BALATON Zoltan :
>
>
>On Tue, 20 Sep 2022, Philippe Mathieu-Daudé via wrote:
>
>> On 20/9/22 01:17, Bernhard Beschow wrote:
>>> These singletons are actually properties of the system bus but so far it
>>> hasn't been modelled that way. Fix this to make
Am 20. September 2022 04:50:51 UTC schrieb "Philippe Mathieu-Daudé"
:
>On 20/9/22 01:17, Bernhard Beschow wrote:
>> The next commit would not compile w/o the include directive.
>>
>> Signed-off-by: Bernhard Beschow
>> ---
>> include/exec/hwaddr.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
Am 20. September 2022 15:36:26 UTC schrieb Mark Cave-Ayland
:
>On 20/09/2022 10:55, Peter Maydell wrote:
>
>> On Tue, 20 Sept 2022 at 00:18, Bernhard Beschow wrote:
>>>
>>> In address-spaces.h it can be read that get_system_memory() and
>>> get_system_io() are temporary interfaces which "should
Am 20. September 2022 09:55:37 UTC schrieb Peter Maydell
:
>On Tue, 20 Sept 2022 at 00:18, Bernhard Beschow wrote:
>>
>> In address-spaces.h it can be read that get_system_memory() and
>> get_system_io() are temporary interfaces which "should only be used
>> temporarily
>> until a proper bus
After expanding bounds checking to use __builtin_dynamic_object_size(),
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance. Avoids
On Tue, Sep 20, 2022 at 2:12 PM Boris Ostrovsky
wrote:
>
> On 9/20/22 10:54 AM, Jan Beulich wrote:
> > On 20.09.2022 16:26, Boris Ostrovsky wrote:
> >> On 9/20/22 4:01 AM, Jan Beulich wrote:
> >>> On 20.09.2022 00:42, Boris Ostrovsky wrote:
> It is saving vpmu data from current pcpu's MSRs
On 9/20/22 10:54 AM, Jan Beulich wrote:
On 20.09.2022 16:26, Boris Ostrovsky wrote:
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @current:
flight 173260 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173260/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit2 14 guest-start fail like 173235
test-armhf-armhf-xl-multivcpu 18
On Tue, 20 Sept 2022 at 17:54, Jan Beulich wrote:
>
> On 20.09.2022 17:36, Ard Biesheuvel wrote:
> > On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> > wrote:
> >>
> >> fwupd requires access to the EFI System Resource Table (ESRT) to
> >> discover which firmware can be updated by the OS.
On 20.09.2022 17:36, Ard Biesheuvel wrote:
> On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> wrote:
>>
>> fwupd requires access to the EFI System Resource Table (ESRT) to
>> discover which firmware can be updated by the OS. Currently, Linux does
>> not expose the ESRT when running as a Xen
On 20/09/2022 10:55, Peter Maydell wrote:
On Tue, 20 Sept 2022 at 00:18, Bernhard Beschow wrote:
In address-spaces.h it can be read that get_system_memory() and
get_system_io() are temporary interfaces which "should only be used temporarily
until a proper bus interface is available". This
Hello Demi,
On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
wrote:
>
> fwupd requires access to the EFI System Resource Table (ESRT) to
> discover which firmware can be updated by the OS. Currently, Linux does
> not expose the ESRT when running as a Xen dom0. Therefore, it is not
> possible
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Wed, 14 Sep 2022 14:43:39 +0800 you wrote:
> The symbol is not used outside of the file, so mark it static.
>
> Fixes the following warning:
>
> ./drivers/net/xen-netfront.c:676:16: warning: symbol
On 17.09.2022 04:51, Marek Marczykowski-Górecki wrote:
> @@ -259,6 +259,9 @@ struct dbc {
> bool open;
> enum xhci_share share;
> unsigned int xhc_num; /* look for n-th xhc */
> +/* state saved across suspend */
> +bool suspended;
> +uint16_t pci_cr;
> };
While perhaps
On 20.09.2022 16:26, Boris Ostrovsky wrote:
> On 9/20/22 4:01 AM, Jan Beulich wrote:
>> On 20.09.2022 00:42, Boris Ostrovsky wrote:
>>> It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
>>> in vmx_find_msr() is not @current:
>>>
>>>vpmu_load()
>>>...
>>>
On 20.09.2022 12:22, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 22, 2022 at 12:00:27PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 22, 2022 at 11:53:50AM +0200, Jan Beulich wrote:
>>> On 21.08.2022 18:14, Marek Marczykowski-Górecki wrote:
On Sat, Oct 09, 2021 at 06:28:17PM
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @current:
vpmu_load()
...
prev = per_cpu(last_vcpu, pcpu);
On Tue, Sep 20, 2022 at 11:06:57AM +0200, Jan Beulich wrote:
> On 19.09.2022 17:09, Marek Marczykowski-Górecki wrote:
> > --- a/xen/common/sched/credit2.c
> > +++ b/xen/common/sched/credit2.c
> > @@ -996,9 +996,13 @@ cpu_add_to_runqueue(const struct scheduler *ops,
> > unsigned int cpu)
> >
On Tue, Aug 23, 2022 at 01:56:22PM +0200, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -55,6 +55,9 @@
> */
> #define HVM_VM86_TSS_SIZE 265
>
> +bool __initdata opt_dom0_assisted_xapic = true;
> +bool __initdata opt_dom0_assisted_x2apic =
Alistair Francis writes:
> On Tue, Sep 20, 2022 at 9:18 AM Bernhard Beschow wrote:
>>
>> SiFiveEState inherits from SysBusDevice while it's TypeInfo claims it to
>> inherit from TYPE_MACHINE. This is an inconsistency which can cause
>> undefined behavior such as memory corruption.
>>
>> Change
On 09-09-22, 16:02, Anthony PERARD wrote:
> On Fri, Sep 09, 2022 at 08:13:28PM +0530, Viresh Kumar wrote:
> > The iommu node will be required for other virtio device types too, not
> > just disk device.
> >
> > Move the call to make_xen_iommu_node(), out of the disk device specific
> > block and
On Mon, Aug 22, 2022 at 12:00:27PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 22, 2022 at 11:53:50AM +0200, Jan Beulich wrote:
> > On 21.08.2022 18:14, Marek Marczykowski-Górecki wrote:
> > > On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > >> On
On Tue, 20 Sept 2022 at 00:18, Bernhard Beschow wrote:
>
> In address-spaces.h it can be read that get_system_memory() and
> get_system_io() are temporary interfaces which "should only be used
> temporarily
> until a proper bus interface is available". This statement certainly extends
> to
>
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file,
Please avoid top-posting.
On Tue, Sep 20, 2022 at 09:41:48AM +0200, Adam Szewczyk wrote:
> > (XEN) MSI132 vec=d9 lowest edge assert log lowest dest=0100
> > mask=0/ /?
> > (XEN)IRQ: 132 vec:d9 PCI-MSI status=030 aff:{8}/{0-11}
> > in-flight=0 d7:151(-M-)
So this is the
Currently the maximum number of NUMA nodes is a hardcoded value.
This provides little flexibility unless changing the code.
Introduce a new Kconfig option to change the maximum number of
NUMA nodes conveniently. Also considering that not all
architectures support NUMA, this Kconfig option is only
x86 has implemented a set of codes to scan NUMA nodes. These
codes will parse NUMA memory and processor information from
ACPI SRAT table. But except some ACPI specific codes, most
of the scan codes like memory blocks validation, node memory
range updates and some sanity check can be reused by
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series - merged in [1]
2. Move generically usable
The sanity check of nodes_cover_memory is also a requirement of
other architectures that support NUMA. But now, the code of
nodes_cover_memory is tied to the x86 E820. In this case, we
introduce arch_get_ram_range to decouple architecture specific
memory map from this function. This means, other
acpi_numa is a specific NUMA switch for ACPI NUMA implementation.
Other NUMA implementation may not need this switch. But this switch is
not only used by ACPI code, it is also used directly in some general
NUMA logic code. So far this hasn't caused any problem because Xen only
has x86 implementing
On 19.09.2022 17:09, Marek Marczykowski-Górecki wrote:
> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -996,9 +996,13 @@ cpu_add_to_runqueue(const struct scheduler *ops,
> unsigned int cpu)
> *
> * Otherwise, let's try to make sure that
On Tue, 20 Sep 2022, Philippe Mathieu-Daudé via wrote:
On 20/9/22 01:17, Bernhard Beschow wrote:
The functions just access a global pointer and perform some pointer
arithmetic on top. Allow the compiler to see through this by inlining.
I thought about this while reviewing the previous
On Tue, 20 Sep 2022, Philippe Mathieu-Daudé via wrote:
On 20/9/22 01:17, Bernhard Beschow wrote:
These singletons are actually properties of the system bus but so far it
hasn't been modelled that way. Fix this to make this relationship very
obvious.
The idea of the patch is to restrain
flight 173259 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173259/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173254
test-armhf-armhf-libvirt 16
On 20.09.2022 00:42, Boris Ostrovsky wrote:
>
>
> On 9/19/22 10:56 AM, Jan Beulich wrote:
>> On 19.09.2022 16:11, Tamas K Lengyel wrote:
>>> On Mon, Sep 19, 2022 at 9:58 AM Jan Beulich wrote:
>>>
On 19.09.2022 15:24, Tamas K Lengyel wrote:
> On Mon, Sep 19, 2022 at 9:21 AM Jan Beulich
On Sat, Aug 20, 2022 at 12:42:50AM -0700, Dongli Zhang wrote:
> Hello,
>
> I used to send out RFC v1 to introduce an extra io_tlb_mem (created with
> SWIOTLB_ANY) in addition to the default io_tlb_mem (32-bit). The
> dev->dma_io_tlb_mem is set to either default or the extra io_tlb_mem,
>
On 20.09.2022 00:42, Stefano Stabellini wrote:
> On Mon, 19 Sep 2022, Jan Beulich wrote:
>> On 16.09.2022 18:05, Carlo Nonato wrote:
>>> On Thu, Sep 15, 2022 at 3:13 PM Jan Beulich wrote:
On 26.08.2022 14:51, Carlo Nonato wrote:
> --- a/xen/arch/arm/Kconfig
> +++
>
> (XEN) Built-in command line: ept=exec-sp spec-ctrl=unpriv-mmio
> (XEN) parameter "no-real-mode" unknown!
> Xen 4.14.5
> (XEN) Xen version 4.14.5 (mockbuild@[unknown]) (gcc (GCC) 10.3.1 20210422
> (Red Hat 10.3.1-1)) debug=n Wed Aug 24 00:00:00 UTC 2022
> (XEN) Latest ChangeSet:
> (XEN)
47 matches
Mail list logo
