On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote:
> On 4/4/22 11:12, Roger Pau Monné wrote:
> > On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote:
> >> On 3/31/22 08:36, Roger Pau Monné wrote:
> >>> On Wed, Mar 30, 2022 at 07:05:48PM -0400, Daniel P. Smith wrote:
>
On Mon, Apr 04, 2022 at 05:33:04PM +0200, Jan Beulich wrote:
> On 04.04.2022 15:22, Roger Pau Monné wrote:
> > On Thu, Mar 31, 2022 at 11:31:38AM +0200, Jan Beulich wrote:
> >> Go a step further than bed9ae54df44 ("x86/time: switch platform timer
> >> hooks to altcall") did and eliminate the "real"
On 30.03.2022 20:17, Jason Andryuk wrote:
> xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
> complete_domain_destroy as an RCU callback. The source context was an
> unexpected, random domain. Since this is a xen-internal operation,
> we don't want the XSM hook denying th
flight 169164 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 169157 REGR. vs. 169145
Tests which are fai
On Mon, Apr 04, 2022 at 05:50:57PM +0200, Jan Beulich wrote:
> (reducing Cc list some)
>
> On 04.04.2022 16:49, Roger Pau Monné wrote:
> > On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
> >> GrUB2 can be told to leave the screen in the graphics mode it has been
> >> using (or any oth
On 31.03.2022 01:05, Daniel P. Smith wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -589,6 +589,9 @@ static void noinline init_done(void)
> void *va;
> unsigned long start, end;
>
> +/* Ensure idle domain was not left privileged */
> +ASSERT(current->domai
On 05.04.2022 10:24, Roger Pau Monné wrote:
> On Mon, Apr 04, 2022 at 05:50:57PM +0200, Jan Beulich wrote:
>> (reducing Cc list some)
>>
>> On 04.04.2022 16:49, Roger Pau Monné wrote:
>>> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
GrUB2 can be told to leave the screen in the
On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
> GrUB2 can be told to leave the screen in the graphics mode it has been
> using (or any other one), via "set gfxpayload=keep" (or suitable
> variants thereof). In this case we can avoid doing another mode switch
> ourselves. This in part
On 31.03.2022 09:14, Michal Orzel wrote:
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -5,4 +5,133 @@
> * Common macros to be used in architecture specific linker scripts.
> */
>
> +/*
> + * To avoid any confusion, please note that the EFI macro does not correspond
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
---
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- Fixed comment (Andrew)
Changes in
This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign
With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.
Given the change, remove
Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.
The feature on arm relies on a spe
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.
Add member to the xen_domctl_createdomain public interface so the
XEN
Add a static function to retrieve the scheduler pointer using the
scheduler name.
Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.
Take the occasion to replace open coded scheduler search with the
new static function in scheduler_
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is possible to allocate a different scheduler for
Hi Jan,
On 05.04.2022 10:49, Jan Beulich wrote:
> On 31.03.2022 09:14, Michal Orzel wrote:
>> --- a/xen/include/xen/xen.lds.h
>> +++ b/xen/include/xen/xen.lds.h
>> @@ -5,4 +5,133 @@
>> * Common macros to be used in architecture specific linker scripts.
>> */
>>
>> +/*
>> + * To avoid any con
This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.
The first patch creates an empty
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.
Include this header in linker scripts for x86 and arm.
This patch serve
Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.
No functional improvements to x86 linker script.
Making use of common macros improves arm linker script with:
- explicit lis
On 05.04.2022 11:16, Michal Orzel wrote:
> Populate header file xen.lds.h with the first portion of macros storing
> constructs common to x86 and arm linker scripts. Replace the original
> constructs with these helpers.
>
> No functional improvements to x86 linker script.
>
> Making use of common
On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote:
> With MB2 the boot loader may provide this information, allowing us to
> obtain it without needing to enter real mode (assuming we don't need to
> set a new mode from "vga=", but can instead inherit the one the
> bootloader may have esta
On 01.04.2022 02:38, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> It will be used during dom0less domains construction.
>
> Signed-off-by: Stefano Stabellini
I think this better wouldn't be a patch of its own. Functions should
be non-static only when they have a user outside of the
On 01.04.2022 17:05, Andrew Cooper wrote:
> On 01/04/2022 15:48, Andrew Cooper wrote:
>> On 01/04/2022 15:37, Roger Pau Monne wrote:
>>> Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in the
>>> Makefile doesn't get it propagated to the subdirectories, so instead
>>> set the flag i
On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote:
> When booting directly from EFI, obtaining this information from EFI is
> the only possible way. And even when booting with a boot loader
> interposed, it's more clean not to use legacy BIOS calls for this
> purpose. (The downside being
flight 169167 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169167/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168315
test-amd64-amd64-qemuu-nested-amd 20 debi
On Thu, Mar 31, 2022 at 11:48:51AM +0200, Jan Beulich wrote:
> There's no point in writing 80x25 text mode information via multiple
> insns all storing immediate values. The data can simply be included
> first thing in the vga_modes table, allowing the already present
> REP MOVSB to take care of ev
On Thu, Mar 31, 2022 at 11:49:24AM +0200, Jan Beulich wrote:
> Using Jcc to branch around a JMP is necessary only in pre-386 code,
> where Jcc is limited to disp8. Use the opposite Jcc directly in two
> places. Since it's adjacent, also convert an ORB to TESTB.
>
> Signed-off-by: Jan Beulich
Rev
On 05.04.2022 11:35, Roger Pau Monné wrote:
> On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -562,12 +562,18 @@ trampoline_setup:
>> mov %esi, sym_esi(xen_phys_start)
>> mov %esi, sym_e
On 05/04/2022 11:18, Jan Beulich wrote:
> On 01.04.2022 17:05, Andrew Cooper wrote:
>> On 01/04/2022 15:48, Andrew Cooper wrote:
>>> On 01/04/2022 15:37, Roger Pau Monne wrote:
Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in the
Makefile doesn't get it propagated to the
Hi Marek,
On 31.03.22 14:36, Marek Marczykowski-Górecki wrote:
On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote:
Maybe some kernel config differences, or other udev rules (memory onlining
is done via udev in my guest)?
I'm seeing:
# zgrep MEMORY_HOTPLUG /proc/config.gz
CONFIG_ARC
On 05.04.2022 12:58, Andrew Cooper wrote:
> On 05/04/2022 11:18, Jan Beulich wrote:
>> On 01.04.2022 17:05, Andrew Cooper wrote:
>>> On 01/04/2022 15:48, Andrew Cooper wrote:
On 01/04/2022 15:37, Roger Pau Monne wrote:
> Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in th
On 05/04/2022 12:04, Jan Beulich wrote:
> On 05.04.2022 12:58, Andrew Cooper wrote:
>> On 05/04/2022 11:18, Jan Beulich wrote:
>>> On 01.04.2022 17:05, Andrew Cooper wrote:
On 01/04/2022 15:48, Andrew Cooper wrote:
> On 01/04/2022 15:37, Roger Pau Monne wrote:
>> Setting the fcf-protec
On Thu, Mar 31, 2022 at 11:50:00AM +0200, Jan Beulich wrote:
> Replace (mainly) MOV forms with shorter insns (or sequences thereof).
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, Mar 31, 2022 at 11:50:20AM +0200, Jan Beulich wrote:
> Replace most LEA instances with (one byte shorter) MOV.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, Mar 31, 2022 at 11:51:02AM +0200, Jan Beulich wrote:
> There's no point going through %ax; the addition can be done directly in
> %di.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
Am 26. März 2022 16:58:23 UTC schrieb Bernhard Beschow :
>igd-passthrough-isa-bridge is only requested in xen_pt but was
>implemented in pc_piix.c. This caused xen_pt to dependend on i386/pc
>which is hereby resolved.
>
>Signed-off-by: Bernhard Beschow
>---
> hw/i386/pc_piix.c| 118 ---
On Tue, Apr 05, 2022 at 12:57:51PM +0200, Jan Beulich wrote:
> On 05.04.2022 11:35, Roger Pau Monné wrote:
> > On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/boot/head.S
> >> +++ b/xen/arch/x86/boot/head.S
> >> @@ -562,12 +562,18 @@ trampoline_setup:
> >>
flight 169166 qemu-mainline real [real]
flight 169176 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169166/
http://logs.test-lab.xenproject.org/osstest/logs/169176/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-26356 / XSA-397
version 2
Racy interactions between dirty vram tracking and paging log dirty hypercalls
UPDATES IN VERSION 2
Public release.
ISSUE DES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-26357 / XSA-399
version 2
race in VT-d domain ID cleanup
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
On 4/5/22 03:42, Roger Pau Monné wrote:
> On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote:
>> On 4/4/22 11:12, Roger Pau Monné wrote:
>>> On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote:
On 3/31/22 08:36, Roger Pau Monné wrote:
> On Wed, Mar 30, 2022 at 07:0
flight 169173 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 4/5/22 04:26, Jan Beulich wrote:
> On 31.03.2022 01:05, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -589,6 +589,9 @@ static void noinline init_done(void)
>> void *va;
>> unsigned long start, end;
>>
>> +/* Ensure idle domain was not le
On 4/5/22 04:18, Jan Beulich wrote:
> On 30.03.2022 20:17, Jason Andryuk wrote:
>> xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
>> complete_domain_destroy as an RCU callback. The source context was an
>> unexpected, random domain. Since this is a xen-internal operation
On Mon, Apr 04, 2022 at 03:42:09PM +0200, Jan Beulich wrote:
> On 01.04.2022 15:46, Marek Marczykowski-Górecki wrote:
> > On Wed, Mar 30, 2022 at 12:16:00PM +0200, Jan Beulich wrote:
> > I'm not sure if "just" bugfix qualify for 4.14 at this point, but if so,
> > I'd propose:
> > 0a20a53df158 tools
flight 169175 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169175/
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
Just disabling cron in rc.d is not enough. There's also anacron which
will get invoked during startup, and since apt-compat has a delay of
up to 30min it can be picked up by the leak detector if the test
finishes fast enough:
LEAKED [process 14563 sleep] process: root 14563 14556 0 07:49 ?
On Sat, Mar 26, 2022 at 05:58:24PM +0100, Bernhard Beschow wrote:
> Now that igd_passthrough_isa_bridge_create() is implemented within the
> xen context it may use Xen* data types directly and become
> xen_igd_passthrough_isa_bridge_create(). This resolves an indirection.
>
> Signed-off-by: Bernha
On Sat, Mar 26, 2022 at 05:58:23PM +0100, Bernhard Beschow wrote:
> igd-passthrough-isa-bridge is only requested in xen_pt but was
> implemented in pc_piix.c. This caused xen_pt to dependend on i386/pc
> which is hereby resolved.
>
> Signed-off-by: Bernhard Beschow
Acked-by: Anthony PERARD
Tha
On 05.04.2022 12:27, Roger Pau Monné wrote:
> On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -568,6 +568,49 @@ static void __init efi_arch_video_init(E
>> #endif
>> }
>>
>> +#ifdef CONFIG_VIDEO
>> +sta
flight 169170 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169170/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 18 guest-localmigrate fail REGR. vs. 168506
build-arm64-xs
On Tue, Apr 5, 2022 at 4:18 AM Jan Beulich wrote:
>
> On 30.03.2022 20:17, Jason Andryuk wrote:
> > xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
> > complete_domain_destroy as an RCU callback. The source context was an
> > unexpected, random domain. Since this is a xe
On Tue, Apr 05, 2022 at 08:06:31AM -0400, Daniel P. Smith wrote:
> On 4/5/22 03:42, Roger Pau Monné wrote:
> > On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote:
> >> On 4/4/22 11:12, Roger Pau Monné wrote:
> >>> On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote:
>
On Tue, Apr 05, 2022 at 04:36:53PM +0200, Jan Beulich wrote:
> On 05.04.2022 12:27, Roger Pau Monné wrote:
> > On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/efi/efi-boot.h
> >> +++ b/xen/arch/x86/efi/efi-boot.h
> >> @@ -568,6 +568,49 @@ static void __init efi_
On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote:
> Hi Marek,
>
> On 31.03.22 14:36, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote:
> > > Maybe some kernel config differences, or other udev rules (memory onlining
> > > is done via
flight 169171 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169171/
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
On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith
wrote:
>
> On 3/31/22 09:16, Jason Andryuk wrote:
> > On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith
> > wrote:
> >>
> >> There are now instances where internal hypervisor logic needs to make
> >> resource
> >> allocation calls that are protected
flight 169177 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169183 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169183/
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
On 4/5/22 13:17, Jason Andryuk wrote:
> On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith
> wrote:
>>
>> On 3/31/22 09:16, Jason Andryuk wrote:
>>> On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith
>>> wrote:
There are now instances where internal hypervisor logic needs to make
resour
On Mon, 4 Apr 2022, Luca Fancellu wrote:
> > On 2 Apr 2022, at 00:14, Demi Marie Obenour
> > wrote:
> >
> > The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> > firmware updates to install. According to the UEFI specification §23.4,
> > the table shall be stored in memory
> On 5 Apr 2022, at 20:21, Stefano Stabellini wrote:
>
> On Mon, 4 Apr 2022, Luca Fancellu wrote:
>>> On 2 Apr 2022, at 00:14, Demi Marie Obenour
>>> wrote:
>>>
>>> The EFI System Resource Table (ESRT) is necessary for fwupd to identify
>>> firmware updates to install. According to the UEFI
Hello everyone,
As announced during earlier community call, I'm posting here to announce our
intention to bootstrap Xen support of AMD SEV-SNP technology. In very short,
this hardware extension on AMD CPUs will allow to run encrypted memory in
guests, except for explicitly permitted areas. The
On 4/4/22 1:05 AM, Christoph Hellwig wrote:
Hi all,
this series tries to clean up the swiotlb initialization, including
that of swiotlb-xen. To get there is also removes the x86 iommu table
infrastructure that massively obsfucates the initialization path.
Git tree:
git://git.infradead.
On Sat, 2 Apr 2022, Julien Grall wrote:
> On 02/04/2022 00:35, Stefano Stabellini wrote:
> > > +/* Return the level where mapping should be done */
> > > +static int xen_pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned
> > > long nr,
> > > +unsigned int flags)
On Sat, 2 Apr 2022, Julien Grall wrote:
> On 02/04/2022 00:53, Stefano Stabellini wrote:
> > On Mon, 21 Feb 2022, Julien Grall wrote:
> > > @@ -1333,21 +1386,34 @@ static int xen_pt_update(unsigned long virt,
> > > while ( left )
> > > {
> > > unsigned int order, level;
> > >
On Sat, 2 Apr 2022, Julien Grall wrote:
> Hi Stefano,
>
> On 02/04/2022 01:00, Stefano Stabellini wrote:
> > On Mon, 21 Feb 2022, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Currently, the function xen_pt_update() will flush the TLBs even when
> > > the mappings are inserted. This i
On Sat, 2 Apr 2022, Julien Grall wrote:
> On 02/04/2022 01:04, Stefano Stabellini wrote:
> > On Mon, 21 Feb 2022, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Now that xen_pt_update_entry() is able to deal with different mapping
> > > size, we can replace the open-coding of the page-t
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, page-table can only be allocated from domheap. This means
> it is not possible to create mapping in the page-tables via
> map_pages_to_xen() if page-table needs to be allocated.
>
> In order to avoid open-coding pag
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> To use properly the fixmap definitions, their user would need
> also new to include . This is not very great when
> the user itself is not meant to directly use ACPI definitions.
>
> Including in is not option because
> the latt
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Wei Liu
>
> The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
> pre-populate all the relevant page tables before the system is fully
> set up.
>
> We will need it on Arm in order to rework the arm64 version of
> xenheap_setup_mappi
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> The numbers of includes in mm.c has been growing quite a lot. However
> some of them (e.g. xen/device_tree.h, xen/softirq.h) doesn't look
> to be directly used by the file or other will be included by
> larger headers (e.g asm/flus
flight 169174 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169174/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
169145
test-amd64-amd64-xl-qemut-win7-amd
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> During early boot, it is not possible to use xen_{,un}map_table()
> if the page tables are not residing the Xen binary.
>
> This is a blocker to switch some of the helpers to use xen_pt_update()
> as we may need to allocate extra
Hi Stefano,
On 05/04/2022 22:12, Stefano Stabellini wrote:
+/* Map a page in a fixmap entry */
+extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __A
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> Currently, memory is added to the boot allocator after the xenheap
> mappings are done. This will break if the first mapping is more than
> 512GB of RAM.
>
> In addition to that, a follow-up patch will rework setup_xenheap_mapping
Hi Stefano,
On 05/04/2022 22:50, Stefano Stabellini wrote:
+static void __init setup_mm(void)
+{
+const struct meminfo *banks = &bootinfo.mem;
+paddr_t ram_start = ~0;
+paddr_t ram_end = 0;
+paddr_t ram_size = 0;
+unsigned int i;
+
+init_pdx();
+
+/*
+ * We need s
flight 169172 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169172/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 19 guest-localmigrate/x10 fail pass in 169163
test-amd64-amd64-xl-qemut-debian
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> The current implementation of setup_xenheap_mappings() is using 1GB
> mappings. This can lead to unexpected result because the mapping
> may alias a non-cachable region (such as device or reserved regions).
> For more details see B
On Mon, 21 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() call by map_pages_to_xen() call.
>
> This has the advantage to remove the differences between 32-bit and
> 64-bit code.
On Tue, 5 Apr 2022, Julien Grall wrote:
> On 05/04/2022 22:50, Stefano Stabellini wrote:
> > > +static void __init setup_mm(void)
> > > +{
> > > +const struct meminfo *banks = &bootinfo.mem;
> > > +paddr_t ram_start = ~0;
> > > +paddr_t ram_end = 0;
> > > +paddr_t ram_size = 0;
> >
On Tue, 5 Apr 2022, Julien Grall wrote:
> On 05/04/2022 22:12, Stefano Stabellini wrote:
> > > +/* Map a page in a fixmap entry */
> > > +extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
> > > +/* Remove a mapping from a fixmap entry */
> > > +extern void clear_fixmap(unsigned
On Fri, 1 Apr 2022, Julien Grall wrote:
> On 01/04/2022 01:35, Stefano Stabellini wrote:
> > > > > > +
> > > > > > +/* Alloc magic pages */
> > > > > > +if (alloc_magic_pages(info, &dom) != 0) {
> > > > > > +printf("Error on alloc magic pages\n");
> > > > > > +return 1;
> >
On Fri, 1 Apr 2022, Juergen Gross wrote:
> On 01.04.22 12:02, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 01/04/2022 01:35, Stefano Stabellini wrote:
> > > > > > > +
> > > > > > > + /* Alloc magic pages */
> > > > > > > + if (alloc_magic_pages(info, &dom) != 0) {
> > > > > > > + pr
On Tue, 5 Apr 2022, Stefano Stabellini wrote:
> On Fri, 1 Apr 2022, Julien Grall wrote:
> > On 01/04/2022 01:35, Stefano Stabellini wrote:
> > > > > > > +
> > > > > > > +/* Alloc magic pages */
> > > > > > > +if (alloc_magic_pages(info, &dom) != 0) {
> > > > > > > +printf("Error on
On 4/1/22 9:21 AM, Chuck Zmudzinski wrote:
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does no
Hi,
On Fri, Mar 11, 2022 at 06:01:11PM -0800, Stefano Stabellini wrote:
> On Wed, 9 Mar 2022, Miaoqian Lin wrote:
> > The of_find_compatible_node() function returns a node pointer with
> > refcount incremented, We should use of_node_put() on it when done
> > Add the missing of_node_put() to releas
On Fri, 1 Apr 2022, Juergen Gross wrote:
> On 01.04.22 12:21, Julien Grall wrote:
> > Hi,
> >
> > I have posted some comments in v3 after you sent this version. Please have a
> > look.
> >
> > On 01/04/2022 01:38, Stefano Stabellini wrote:
> > > +static int init_domain(struct xs_handle *xsh, libx
flight 169178 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169178/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169162
test-amd64-amd64-xl-qemut-win7-a
On 05.04.22 18:24, Marek Marczykowski-Górecki wrote:
On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote:
Hi Marek,
On 31.03.22 14:36, Marek Marczykowski-Górecki wrote:
On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote:
Maybe some kernel config differences, or other udev
flight 169180 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168481
test-amd64-i386-xl-qemuu-win7-am
flight 169179 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169179/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169119
test-amd64-amd64-xl-qemuu-win7-a
Fold each branch into its only caller.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_main.c | 50 --
1 file changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 9676a1d214bc5.
Hi Jens,
this series cleanups up the block layer API so that APIs consumed
by file systems are (almost) only struct block_devic based, so that
file systems don't have to poke into block layer internals like the
request_queue.
I also found a bunch of existing bugs related to partition offsets
and
For block devices the target code implements UNMAP as calls to
blkdev_issue_discard, which does not guarantee zeroing just because
Write Zeroes is supported.
Note that this does not affect the file backed path which uses
fallocate to punch holes.
Fixes: 2237498f0b5c ("target/iblock: Convert WRITE
The target code is a consumer of the block layer and should generally
work on struct block_device.
Signed-off-by: Christoph Hellwig
---
drivers/target/target_core_device.c | 5 +++--
drivers/target/target_core_file.c| 7 ---
drivers/target/target_core_iblock.c | 2 +-
include/target/ta
Use the proper bdev_discard_alignment helper that accounts for partition
offsets.
Fіxes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6")
Signed-off-by: Christoph Hellwig
---
drivers/target/target_core_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
Sanitize the calling conventions and use a goto label to cleanup the
code flow.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_nl.c | 68 +++-
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/bloc
Signed-off-by: Christoph Hellwig
---
fs/ntfs3/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c
index 278dcf5024102..cd30e81abbce0 100644
--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -920,7 +920,7 @@ static int ntfs_fill_super(stru
1 - 100 of 121 matches
Mail list logo
