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):
test-am
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 TYPE_MACHIN
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 e85b
[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 pass
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):
test-armhf-
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 can
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 thi
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 thi
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 int
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 t
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 f
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:
vpmu_load
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 guest-
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. Curr
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 do
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 sta
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 t
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 'bounce_skb'
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 +02
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);
vpmu_save_
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 = t
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 S
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 r
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 Su
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
> the
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, "MAX
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 M
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 other
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
an
(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 cod
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 ar
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 siblin
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 patch
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 futhe
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 save
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,
> dependin
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
> +++ b/xen/arch/arm/Kconfi
>
> (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) Bootlo
47 matches
Mail list logo