>>> On 26.04.19 at 23:31, wrote:
> On 4/26/19 4:48 PM, Jan Beulich wrote:
> On 26.04.19 at 17:38, wrote:
>>> May I ask why it is currently not be an issue on x86? Do you always pass a
>>> power
>>> of 2 to init_xenheap_pages?
>>
>> No, it's because CONFIG_SEPARATE_XENHEAP is undefined on
>>
flight 135343 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135343/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf
>>> On 27.04.19 at 01:47, wrote:
> The other change to nr_pdxs is less obvious. It is clear that nr_pdxs is
> calculated wrongly in this case (memory 0-0x8000,
> 0x8-0x88000, ps=0, pe=0x88000): nr_pdxs=524288 which is
> half the number we need (the correct number is 1048575).
>
On Sun, Apr 28, 2019 at 09:08:23PM +0200, Marek Marczykowski-Górecki wrote:
> Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> toolstack" changed meaning of virt_caps bit 1 - previously it was
> "directio", but was changed to "pv" and "directio" was moved to bit 2.
> Adjust py
Sorry for top posting...
FYI, I am on vacation right now. I will be back next week. So, if it is
not urgent I will explain all the stuff and update relevant bug at the
beginning of next week. Sorry for delay.
Daniel
On Sun, Apr 28, 2019 at 12:44:37PM +1000, Steven Haigh wrote:
> (and sending to
flight 135349 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken
test-amd64-amd64
I have not heard that Peter moved to the Oracle ;-))), so, changing his
address back to RedHat one. And dropping Fedora testing mailing list
address because I do not have permissions to send to it...
On Mon, Apr 29, 2019 at 10:51:47AM +0200, Daniel Kiper wrote:
> Sorry for top posting...
>
> FYI,
Marek Marczykowski-Górecki writes ("[PATCH] python: Adjust xc_physinfo wrapper
for updated virt_caps bits"):
> Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> toolstack" changed meaning of virt_caps bit 1 - previously it was
> "directio", but was changed to "pv" and "directi
flight 135371 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135371/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-amd64
flight 135351 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135351/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-xsm
We need to keep up with a d-i update by Debian.
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index 5b9f5c82..882dabc6 100644
--- a/production-config
+++ b/production-config
@@ -90,7 +90,
Hello,
>
> The proper way is to detect PPI before hand and completely skip the node if
> any.
I tried the following change:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..a9ecfed 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@
On 29/04/2019 11:52, Amit Tomer wrote:
Hello,
Hi,
The proper way is to detect PPI before hand and completely skip the node if any.
I tried the following change:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..a9ecfed 100644
--- a/xen/arch/arm/domain_b
The cleanup IPI may get sent immediately before a CPU gets removed from
the online map. In such a case the IPI would get handled on the CPU
being offlined no earlier than in the interrupts disabled window after
fixup_irqs()' main loop. This is too late, however, because a possible
affinity change m
desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
fiddle with desc->affinity itself, except to store caller requested
values.
This renders both set_native_irq_info() uses (which weren't using proper
locking anyway) redundant - drop the function altogether.
Signed-off-by: Jan
First and foremost this series is trying to deal with CPU offlining
issues, which have become more prominent with the recently
added SMT enable/disable operation in xen-hptool. Later patches
in the series then carry out more or less unrelated changes
(hopefully improvements) noticed while looking a
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -35,8 +35,8 @@ struct arch_irq_desc {
cpumask_var_t cpu_mask;
cpumask_var_t old_cpu_mask;
cpumask_var_t pending_mask;
-unsigned move_cleanup_count;
vmask_t *us
The subsequent cpumask_intersects() covers the "empty" case quite fine.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -638,9 +638,6 @@ void move_masked_irq(struct irq_desc *de
desc->status &= ~IRQ_MOVE_PENDING;
-if (unlikely(cpumask_empty(pendin
Must be a left-over from earlier days.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -984,8 +984,6 @@ static void __init setup_IO_APIC_irqs(vo
for (apic = 0; apic < nr_ioapics; apic++) {
for (pin = 0; pin < nr_ioapic_entries[apic]; pin++)
flight 135403 freebsd-master running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135403/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd-again queued
build-amd64-xen-fr
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() and destroy_irq(), which also clarifies what the
nesting behavior between the l
Don't log a stray trailing comma. Shorten a few fields.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2318,7 +2318,7 @@ static void dump_irqs(unsigned char key)
spin_lock_irqsave(&desc->lock, flags);
-printk(" IRQ:%4d affinity:%*pb vec:%0
Since the "Cannot set affinity ..." warning is a one time one, avoid
triggering it already at boot time when parking secondary threads and
the serial console uses a (still unconnected at that time) PCI IRQ.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2412,8 +
flight 135409 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135409/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 queued
test-amd64-i
flight 135384 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135384/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
flight 135401 qemu-upstream-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135401/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
bui
On 29/04/2019 12:27, Jan Beulich wrote:
> Must be a left-over from earlier days.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 29/04/2019 12:25, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 135377 linux-3.18 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135377/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-arm64-xsm
flight 135398 qemu-upstream-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135398/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
bui
On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
>
> On 3/27/2019 7:21 AM, Jan Beulich wrote:
> > > > > On 27.03.19 at 14:25, wrote:
> > > On 3/27/2019 1:14 AM, Jan Beulich wrote:
> > > > > > > On 26.03.19 at 18:21, wrote:
> > > > > zeta /usr/local/src/xen # cat xen/.config |grep C
flight 135383 qemu-upstream-4.10-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135383/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
bui
flight 135395 linux-4.19 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135395/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-amd64-pvops
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Xen build system may enforce particular gcc version (e.g. gcc72).
Make sure the livepatch-gcc script accepts all input toolchain gcc
commands with or without version specified.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Mazein
Reviewe
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Do not copy over the built_in.o and prelink.o object files when they
get rebuilt as they are used for transient linking by Xen's build
system.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Pohlack
Reviewed-by: Petre Eftime
Reviewed-by
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
In some build systems symlinks might be used for patch file names
to point from target directories to actual patches. Following those
symlinks breaks naming convention as the resulting built modules
would be named after the actual hardlink insteads o
flight 135399 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135399/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On 08/04/2019 09:32, Pawel Wieczorkiewicz wrote:
> Up to now the livepatch-build ignores newly created object files.
> When patch applies new .c file and augments its Makefile to build it
> the resulting object file is not taken into account for final linking
> step.
>
> Such newly created object f
flight 135397 xen-4.9-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135397/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-i386-pre
flight 135386 linux-4.14 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135386/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64-xsm
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main differ
flight 135374 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135374/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
>>> On 29.04.19 at 14:55, wrote:
On 29.04.19 at 13:22, wrote:
>> RFC: I've seen the new ASSERT() in irq_move_cleanup_interrupt() trigger.
>> I'm pretty sure that this assertion triggering means something else
>> is wrong, and has been even prior to this change (adding the
>> a
flight 135402 linux-next running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135402/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-amd64-xsm
flight 135373 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135373/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-arm64
flight 135400 xen-4.8-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135400/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
build-i386-xsm
flight 135396 linux-4.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135396/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
flight 135378 linux-4.9 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135378/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-amd64-pvops
flight 135407 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135407/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt queued
test-amd64-amd64-xl-qemuu-ov
On 4/29/19 1:53 PM, Andrew Cooper wrote:
On 08/04/2019 09:32, Pawel Wieczorkiewicz wrote:
Up to now the livepatch-build ignores newly created object files.
When patch applies new .c file and augments its Makefile to build it
the resulting object file is not taken into account for final linking
s
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Up to now the livepatch-build ignores newly created object files.
When patch applies new .c file and augments its Makefile to build it
the resulting object file is not taken into account for final linking
step.
Such newly created object files can be
>>> On 29.04.19 at 13:22, wrote:
> RFC: I've seen the new ASSERT() in irq_move_cleanup_interrupt() trigger.
> I'm pretty sure that this assertion triggering means something else
> is wrong, and has been even prior to this change (adding the
> assertion without any of the other chang
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.
This is a livepatch backport of kpatch upstream commit [1]:
kpatch-build: detect special
On 4/25/19 5:53 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Apr 16, 2019 at 12:07:14PM +, Pawel Wieczorkiewicz wrote:
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.
This is a livepa
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any hotpatches built for different
hypervisor version as indicated by the Xen Bu
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatibl
On 4/29/19 3:10 PM, Ross Lagerwall wrote:
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.
This is a livepatch backport of kpatch upstre
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_P
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c
On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Wei Liu
> Cc: Roger Pau Monne
> ---
> v3: simplified p
On 4/25/19 5:51 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Apr 16, 2019 at 12:22:39PM +, Pawel Wieczorkiewicz wrote:
When there is no changed function in the generated payload, do not
create an empty .livepatch.funcs section. Hypervisor code considers
such payloads as broken and rejects to loa
Julien Grall writes ("Re: [OSSTEST PATCH 00/21] Abandon jobs which are
unreasonably delaying their flight"):
> As we discussed on IRC, I understand this will have an impact on Arm32
> testing. Do you have an estimate how likely the tests will be skipped?
Many, maybe most. Very likely the smoke
On 4/29/19 3:32 PM, George Dunlap wrote:
> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>> Calling _put_page_type while also holding the page_lock
>> for that page can cause a deadlock.
>>
>> Signed-off-by: Tamas K Lengyel
>> Cc: Jan Beulich
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Wei Li
>>> On 23.04.19 at 16:30, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
> mm_write_unlock(&p2m->lock);
> }
>
> +int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t
>
On 4/29/19 3:49 PM, Andrew Cooper wrote:
> On 29/04/2019 15:46, George Dunlap wrote:
>> On 4/29/19 3:32 PM, George Dunlap wrote:
>>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
Signed-off-
>>> On 26.04.19 at 19:21, wrote:
> --- a/xen/include/asm-x86/mem_sharing.h
> +++ b/xen/include/asm-x86/mem_sharing.h
> @@ -25,7 +25,9 @@
> #include
>
> /* Auditing of memory sharing code? */
> +#ifndef NDEBUG
> #define MEM_SHARING_AUDIT 1
> +#endif
Since consumers use #if (not #ifdef), I th
On 29/04/2019 15:46, George Dunlap wrote:
> On 4/29/19 3:32 PM, George Dunlap wrote:
>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>>> Calling _put_page_type while also holding the page_lock
>>> for that page can cause a deadlock.
>>>
>>> Signed-off-by: Tamas K Lengyel
>>> Cc: Jan Beulich
>>> Cc:
>>> On 26.04.19 at 19:21, wrote:
> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> shr_handle_t sh,
> mem_sharing_page_unlock(secondpg);
> mem_sharing_page_unlock(firstpg);
>
> +BUG_ON(!put_count);
> +while ( put_count-- )
> +put_page_and_t
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Detect standard (always to be included) sections via their section
header type. The standard sections: ".shstrtab", ".symtab", ".strtab"
are either of type SHT_SYMTAB or SHT_STRTAB.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Para
Julien Grall writes ("Re: [OSSTEST PATCH 14/15] cross builds: Build armhf
kernels on amd64 hosts"):
> On 4/26/19 5:40 PM, Ian Jackson wrote:
> > Our armhf hosts are devboards and very slow, as well as scarce. It
> > 5takes 17ks or so for a kernel build. This will go *much* faster on
>
> NIT: s/
On 4/29/2019 5:02 AM, Roger Pau Monné wrote:
On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
On 3/27/2019 7:21 AM, Jan Beulich wrote:
On 27.03.19 at 14:25, wrote:
On 3/27/2019 1:14 AM, Jan Beulich wrote:
On 26.03.19 at 18:21, wrote:
zeta /usr/local/src/xen # cat xen/.config
Julien Grall writes ("Re: [OSSTEST PATCH 11/15] cross builds: ts-kernel-build:
Support cross target armhf"):
> On 4/26/19 10:23 PM, Julien Grall wrote:
> > NIT: HOSTCC is not necessary. It will be default to gcc if not passed.
I will drop it.
> > Otherwise, the export looks write to me.
Thanks
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
This function checks if given section has an included corresponding
RELA section and/or any of the symbols table symbols references the
section. Section associated symbols are ignored here as there is
always such a symbol for every section.
Signed-
>>> On 26.04.19 at 19:21, wrote:
> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> put_page_type
> ordering" added extra sanity checking to page_lock/page_unlock for debug
> builds
> with the assumption that no hypervisor path ever locks two pages at once.
>
> This assumptio
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
This function determines, based on the given section name, if the
sections belongs to the special sections category.
It treats a name from the special_sections array as a prefix. Any
sections whose name starts with special section prefix is consider
On advice from Wei, I am about to push this squashed backport to the
stable trees. We think this will help fix osstest on those branches
following the upgrade to Debian stretch.
Ian.
From e983e8ae84efd5e43045a3d20a820f13cb4a75bf Mon Sep 17 00:00:00 2001
From: Wei Liu
Date: Wed, 28 Nov 2018 17:4
Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile, when
necessary"):
> On advice from Wei, I am about to push this squashed backport to the
> stable trees. We think this will help fix osstest on those branches
> following the upgrade to Debian stretch.
Now done, including
>>> On 26.04.19 at 19:21, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -17,7 +17,6 @@ config X86
> select HAS_KEXEC
> select MEM_ACCESS_ALWAYS_ON
> select HAS_MEM_PAGING
> - select HAS_MEM_SHARING
> select HAS_NS16550
> select HAS_PASSTHRO
On Mon, Apr 29, 2019 at 8:57 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > --- a/xen/include/asm-x86/mem_sharing.h
> > +++ b/xen/include/asm-x86/mem_sharing.h
> > @@ -25,7 +25,9 @@
> > #include
> >
> > /* Auditing of memory sharing code? */
> > +#ifndef NDEBUG
> > #define MEM
On Mon, Apr 29, 2019 at 08:08:33AM -0700, John L. Poole wrote:
>
> On 4/29/2019 5:02 AM, Roger Pau Monné wrote:
> > On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
> > > On 3/27/2019 7:21 AM, Jan Beulich wrote:
> > > > > > > On 27.03.19 at 14:25, wrote:
> > > > > On 3/27/2019 1:14
On Mon, Apr 29, 2019 at 8:54 AM George Dunlap wrote:
>
> On 4/29/19 3:49 PM, Andrew Cooper wrote:
> > On 29/04/2019 15:46, George Dunlap wrote:
> >> On 4/29/19 3:32 PM, George Dunlap wrote:
> >>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_l
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> > shr_handle_t sh,
> > mem_sharing_page_unlock(secondpg);
> > mem_sharing_page_unlock(firstpg);
> >
> > +BUG_ON(!
On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
I can't immediately see what the mem_sharing_page_[un]lock() functions
are meant to be protecting against. Is there a comment anywhere
describing what they're
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section follow
On Mon, Apr 29, 2019 at 9:32 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -17,7 +17,6 @@ config X86
> > select HAS_KEXEC
> > select MEM_ACCESS_ALWAYS_ON
> > select HAS_MEM_PAGING
> > - select
On 4/29/19 4:41 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
>>
> On 26.04.19 at 19:21, wrote:
>>> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
>>> shr_handle_t sh,
>>> mem_sharing_page_unlock(secondpg);
>>> mem_shari
Hi,
On 29/04/2019 08:15, Jan Beulich wrote:
On 27.04.19 at 01:47, wrote:
The other change to nr_pdxs is less obvious. It is clear that nr_pdxs is
calculated wrongly in this case (memory 0-0x8000,
0x8-0x88000, ps=0, pe=0x88000): nr_pdxs=524288 which is
half the number we nee
On Mon, Apr 29, 2019 at 9:44 AM George Dunlap wrote:
>
> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> > Calling _put_page_type while also holding the page_lock
> > for that page can cause a deadlock.
>
> I can't immediately see what the mem_sharing_page_[un]lock() functions
> are meant to be prote
On Mon, Apr 29, 2019 at 9:52 AM George Dunlap wrote:
>
> On 4/29/19 4:41 PM, Tamas K Lengyel wrote:
> > On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
> >>
> > On 26.04.19 at 19:21, wrote:
> >>> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t
> >>> sgfn, shr_handle_
>>> On 29.04.19 at 17:54, wrote:
> Anyway, I also tested the change suggested by Stefano. This will
> substantially
> increase the size of the frametable on platform where the RAM does not start
> at 0.
>
> For instance, on Foundation Model the RAM starts at 2GB. As we don't compress
> any of
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Starting with the "2af6f1aa6233 Fix patch creation with GCC 6.1+" commit
all .rodata sections are included by default (regardless of whether they
are needed or not).
During stacked hotpatch builds it leads to unnecessary duplication of
the .rodata s
>>> On 29.04.19 at 18:05, wrote:
> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
> wrote:
>> I haven't re-grokked the code here, but assuming I was correct 2 weeks
>> ago, if you have the BUG_ON() there, you can get rid of the extra
>> references.
>
> Sure, but again, the overhead of having the
Patch 1 is applicable to Xen 4.10 and 4.11
Patch 2 is applicable to just Xen 4.11
Andrew Cooper (2):
xen: Fix backport of "xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s)
construct"
xen: Fix backport of "x86/tsx: Implement controls for RTM force-aborte mode"
xen/arch/x86/cpu/vpmu.c |
The posted version of this patch depends on c/s 3c555295 "x86/vpmu: Improve
documentation and parsing for vpmu=" (Xen 4.12 and later) to prevent
`vpmu=rtm-abort` impliying `vpmu=1`, which is outside of security support.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
xen/arch/x86/cpu/vpmu.c |
These were missed as a consequence of being rebased over other cmdline
cleanup.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
xen/arch/x86/dom0_build.c | 4 ++--
xen/arch/x86/hvm/vmx/vmcs.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c
On 4/29/19 5:14 PM, Jan Beulich wrote:
On 29.04.19 at 18:05, wrote:
>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>> wrote:
>>> I haven't re-grokked the code here, but assuming I was correct 2 weeks
>>> ago, if you have the BUG_ON() there, you can get rid of the extra
>>> references.
>>
On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
>
> >>> On 29.04.19 at 18:05, wrote:
> > On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
> > wrote:
> >> I haven't re-grokked the code here, but assuming I was correct 2 weeks
> >> ago, if you have the BUG_ON() there, you can get rid of the extr
On 4/29/19 5:26 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
>>
> On 29.04.19 at 18:05, wrote:
>>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>>> wrote:
I haven't re-grokked the code here, but assuming I was correct 2 weeks
ago, if you have t
1 - 100 of 120 matches
Mail list logo
