On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
> All,
>
> the release is due in early August. Please point out backports you
> find missing from the respective staging branch, but which you
> consider relevant. The one commit I've queued already on top of
> what was just pushed is
>
From: Andrew Cooper
The XPTI work restricted the visibility of most of memory, but missed a few
aspects when it came to the TSS.
Given that the TSS is just an object in percpu data, the 4k mapping for it
created in setup_cpu_root_pgt() maps adjacent percpu data, making it all
leakable via Meltd
On 12.08.2019 09:17, Roger Pau Monné wrote:
On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
the release is due in early August. Please point out backports you
find missing from the respective staging branch, but which you
consider relevant. The one commit I've queued already on top
On 09.08.2019 12:40, Jan Beulich wrote:
There is plenty more cleanup which can be done in the future. As we are
64-bit, there is no need for load_TR() to keep the TSS in sync between the two
GDTs, which means it can drop all sgdt/lgdt instructions.
I'm trying to figure what exactly you mean he
On 09.08.2019 19:16, Andrew Cooper wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1914,7 +1914,7 @@ By default SSBD will be mitigated at runtime (i.e
`ssbd=runtime`).
### spec-ctrl (x86)
> `= List of [ , xen=, {pv,hvm,msr-sc,rsb,md-clear}=,
>
On Sun, Aug 11, 2019 at 12:23:22PM -0500, Wenwen Wang wrote:
> In read_per_ring_refs(), after 'req' and related memory regions are
> allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
> etc. However, if this mapping process fails, no cleanup is performed,
> leading to memory le
Ping?
I know I've posted this quite recently, but have you been able to test
the two proposed patches?
ie: the one here and:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00643.html
I would like to figure out exactly what's going on and fix this
properly.
Thanks, Roger.
On W
On 09.08.2019 17:01, David Woodhouse wrote:
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -735,7 +735,17 @@ trampoline_setup:
/* Switch to low-memory stack which lives at the end of trampoline
region. */
mov sym_fs(trampoline_phys),%edi
lea T
On 09.08.2019 17:01, David Woodhouse wrote:
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -16,21 +16,62 @@
* not guaranteed to persist.
*/
-/* NB. bootsym() is only usable in real mode, or via BOOT_PSEUDORM_DS. */
+/*
+ * There are four sets of relocations
On 09.08.2019 17:02, David Woodhouse wrote:
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -733,6 +733,17 @@ trampoline_setup:
cmp $sym_offs(__bootsym_seg_stop),%edi
jb 1b
+/* Relocations for the boot data section. */
+mov sym_fs
On 12/08/2019 08:23, Jan Beulich wrote:
> @@ -747,16 +747,10 @@ void load_system_tables(void)
> .bitmap = IOBMP_INVALID_OFFSET,
> };
>
> - _set_tssldt_desc(
> - gdt + TSS_ENTRY,
> - (unsigned long)tss,
> - offsetof(struct tss_struct, __cacheline_filler) - 1,
On 12/08/2019 08:32, Jan Beulich wrote:
> On 09.08.2019 12:40, Jan Beulich wrote:
>> There is plenty more cleanup which can be done in the future. As we are
>> 64-bit, there is no need for load_TR() to keep the TSS in sync
>> between the two
>> GDTs, which means it can drop all sgdt/lgdt instructi
> -Original Message-
> From: George Dunlap
> Sent: 02 August 2019 16:28
> To: Jan Beulich ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
Hi,
On 09/08/2019 23:56, Stefano Stabellini wrote:
On Thu, 8 Aug 2019, Volodymyr Babchuk wrote:
Hi Stefano,
Stefano Stabellini writes:
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_p
On 09.08.2019 17:02, David Woodhouse wrote:
From: David Woodhouse
Where booted from EFI or with no-real-mode, there is no need to stomp
on low memory with the 16-boot code. Instead, just go straight to
trampoline_protmode_entry() at its physical location within the Xen
image.
For now, the boot
On 8/12/19 11:38 AM, Paul Durrant wrote:
>> -Original Message-
>> From: George Dunlap
>> Not terrible for such a wonkily-behaving guest; but I think I'd rather
>> go with the "special-case xenheap pages" option.
>
> Ok, I see you've committed a patch to that effect while I was away.
Yes;
Hi Oleksandr,
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.
In order not to pull Linux's error code (-EPROB
On 12.08.19 14:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a
flight 139942 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 139972 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 139829
build-i386-libvirt
On 12/08/2019 12:04, Jan Beulich wrote:
> On 12.08.2019 12:29, Andrew Cooper wrote:
>> On 12/08/2019 08:23, Jan Beulich wrote:
>>> @@ -747,16 +747,10 @@ void load_system_tables(void)
>>> .bitmap = IOBMP_INVALID_OFFSET,
>>> };
>>> - _set_tssldt_desc(
>>> - gdt + TSS_ENTRY
On 8/2/19 10:22 AM, Roger Pau Monne wrote:
> Switch rmrr_identity_mapping to use iommu_{un}map in order to
> establish RMRR mappings for PV domains, like it's done in
> arch_iommu_hwdom_init. This solves the issue of a PV hardware domain
> not getting RMRR mappings because {set/clear}_identity_p2m_
On Mon, Aug 12, 2019 at 02:17:53PM +0100, George Dunlap wrote:
> On 8/2/19 10:22 AM, Roger Pau Monne wrote:
> > Switch rmrr_identity_mapping to use iommu_{un}map in order to
> > establish RMRR mappings for PV domains, like it's done in
> > arch_iommu_hwdom_init. This solves the issue of a PV hardwa
On 8/11/19 10:23 AM, Wenwen Wang wrote:
> In read_per_ring_refs(), after 'req' and related memory regions are
> allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
> etc. However, if this mapping process fails, no cleanup is performed,
> leading to memory leaks. To fix this issu
flight 139987 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139987/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
On 8/12/19 2:56 PM, Roger Pau Monné wrote:
> On Mon, Aug 12, 2019 at 02:17:53PM +0100, George Dunlap wrote:
>> On 8/2/19 10:22 AM, Roger Pau Monne wrote:
>>> Switch rmrr_identity_mapping to use iommu_{un}map in order to
>>> establish RMRR mappings for PV domains, like it's done in
>>> arch_iommu_hw
Hi George,
On 12/08/2019, 12:35, "George Dunlap" wrote:
On 8/9/19 6:48 PM, Lars Kurth wrote:
> Hi all,
>
> Following the discussion we had at the Developer Summit (see
https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Co
On 8/12/19 3:27 PM, Lars Kurth wrote:
> I am wondering how you feel about the usage of "participant". There are
> a few instances left in the text.
>
> "Any report of harassment within the Xen Project community will be addressed
> swiftly. Participants asked to stop ..."
>
> # Consequences of
On Thu, Aug 08, 2019 at 05:18:15PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote:
> > So EDKII doesn't have that capability, FSBClock is a build time value
> > and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use
> > that value at a
> -Original Message-
> From: Jan Beulich
> Sent: 07 August 2019 10:56
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Brian Woods ;
> Suravee Suthikulpanit
> ; Julien Grall ; Andrew
> Cooper
> ; Roger Pau Monne ;
> VolodymyrBabchuk
> ; George Dunlap ; Jun
> Nakajima
> ; Kevin
On Mon, Aug 12, 2019 at 03:24:36PM +0100, George Dunlap wrote:
> On 8/12/19 2:56 PM, Roger Pau Monné wrote:
> > On Mon, Aug 12, 2019 at 02:17:53PM +0100, George Dunlap wrote:
> >> On 8/2/19 10:22 AM, Roger Pau Monne wrote:
> >>> Switch rmrr_identity_mapping to use iommu_{un}map in order to
> >>> es
On 12/08/2019 15:53, George Dunlap wrote:
> On 8/8/19 10:13 AM, Julien Grall wrote:
>> Hi Jan,
>>
>> On 08/08/2019 10:04, Jan Beulich wrote:
>>> On 08.08.2019 10:43, Andrew Cooper wrote:
On 08/08/2019 07:22, Jan Beulich wrote:
> On 07.08.2019 21:41, Andrew Cooper wrote:
>> --- /dev/nul
mov/shr is easier to follow than shld, and doesn't have a merge dependency on
the previous value of %edx. Shorten the rest of the code by streamlining the
comments.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
In addition to being clearer to follow, mov/sh
On Mon, Aug 12, 2019 at 04:15:38PM +0100, George Dunlap wrote:
> On 8/12/19 3:55 PM, Roger Pau Monné wrote:
> > On Mon, Aug 12, 2019 at 03:24:36PM +0100, George Dunlap wrote:
> >> On 8/12/19 2:56 PM, Roger Pau Monné wrote:
> >>> On Mon, Aug 12, 2019 at 02:17:53PM +0100, George Dunlap wrote:
>
flight 139967 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139967/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4053587347a4c68402c1fc40921b7f1cdaec900e
baseline version:
ovmf 1a624dd7cf0db5783b27e
On Sat, 2019-08-10 at 20:12 +0200, Dridi Boukelmoune wrote:
> Sorry for the top posting, "smart" phone...
>
> What about Qubes OS? Isn't their dom0 using xen, based on Fedora?
>
> Do they use Xen as packaged by Fedora? If not, couldn't they contribute
> whatever they do that Fedora doesn't here?
flight 140001 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
c/s 650c31d3af "x86/IRQ: fix locking around vector management" adjusted the
locking in adjust_irq_affinity().
The S3 path ends up here via iommu_resume() before interrupts are enabled, at
which point spin_lock_irq() which fail ASSERT(local_irq_is_enabled()); but
with no working console.
Use spin_
At the moment, the user should save r14/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register r0
if it was stored in a different register.
For convenience, a new macro
At the moment, TTBR_EL2 is setup in create_page_tables(). This is fine
as it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the TTBR_EL2 is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the TTBR_EL2 is
seen
A follow-up patch will require to use *_table_offset() and *_MASK helpers
from assembly. This can be achieved by using _AT() macro to remove the type
when called from assembly.
Signed-off-by: Julien Grall
---
Changes in v3:
- Patch added
---
xen/include/asm-arm/lpae.h | 10 +
Document the behavior and the main registers usage within the function.
Note that r6 is now only used within the function, so it does not need
to be part of the common register.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v3:
- Add Stefano's acked-by
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v3:
- Add Stefano's acked-by
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 7 +++
1 file changed, 7 ins
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at Hypervisor Mode.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
Changes in v2:
The current boot code is using the pattern ldr rX, =... to move an
immediate constant into a 32-bit register.
This pattern implies to load the immediate constant from a literal pool,
meaning a memory access will be performed.
The memory access can be avoided by using movw/movt instructions.
A ne
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate function
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid using conditional instruction and make the call
clearer, launch() is reworked to take in parameters the entry point and its
arguments.
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
Hi all,
This is part of the boot/memory rework for Xen on Arm, but not sent as
MM-PARTx as this is focusing on the boot code.
Similar to the memory code, the boot code is not following the Arm Arm and
could lead to memory corruption/TLB conflict abort. I am not aware
of any platforms where Xen fa
At the moment the function create_page_tables() will use 1GB/2MB
mapping for the identity mapping. As we don't know what is present
before and after Xen in memory, we may end up to map
device/reserved-memory with cacheable memory. This may result to
mismatched attributes as other users may access t
At the moment, any update to the boot-pages are open-coded. This is
making more difficult to understand the logic of a function as each
update roughly requires 6 instructions.
To ease the readability, two new macros are introduced:
- create_table_entry: Create a page-table entry in a given tab
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
At the moment the function create_page_tables() will use 1GB/2MB
mapping for the identity mapping. As we don't know what is present
before and after Xen in memory, we may end up to map
device/reserved-memory with cacheable memory. This may result to
mismatched attributes as other users may access t
At the moment, HTTBR is setup in create_page_tables(). This is fine as
it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the HTTBR is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the HTTBR is
seen before t
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid a branch for the decision and make the code clearer,
launch() is reworked to take in parameters the entry point and its
arguments.
La
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if earlyp
The current implementation of the macro PRINT will clobber r14/lr. This
means the user should save r14 if it cares about it.
Follow-up patches will introduce more use of PRINT in places where lr
should be preserved. Rather than requiring all the user to preserve lr,
the macro PRINT is modified to
On 12/08/2019 18:30, Julien Grall wrote:
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
Hmmm, I made a typo in Stefano's e-mail address. I can fix it on commit message
(o
On Mon, Aug 12, 2019 at 06:52:05PM +0100, Andy Cooper wrote:
> ... to avoid having multiple spin_unlock_irqrestore() calls.
>
> Signed-off-by: Andrew Cooper
Acked-by: Brian Woods
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
flight 139966 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129313
build-armhf-pvops
It is never written to.
This was an oversight when it was moved from asm into C.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/desc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/desc.c b/xen/arch/x86/des
load_TR() is used exclusively in the resume path, but jumps through a lot of
unnecessary hoops.
As suspend/resume is strictly on CPU0 in idle context, the correct GDT to use
is boot_gdt, which means it doesn't need saving on suspend. Similarly, the
correct IDT to use can be derived, and the LDT i
This started off as "get rid of load_TR()" as identified in the TSS cleanup
series, and morphed slightly.
Andrew Cooper (3):
x86/suspend: Sanity check more properties in enter_state()
x86/desc: Move boot_gdtr into .rodata
x86/suspend: Simplify system table handling on resume
xen/arch/x86/a
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xe
Hi Oleksandr,
On 8/12/19 1:01 PM, Oleksandr wrote:
On 12.08.19 14:11, Julien Grall wrote:
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting d
flight 140013 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140013/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
When freeing a p2m entry, all the sub-tree behind it will also be freed.
This may include intermediate page-tables or any l3 entry requiring to
drop a reference (e.g for foreign pages). As soon as pages are freed,
they may be re-used by Xen or another domain. Therefore it is necessary
to flush *all
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled accordingly:
consider_modules and dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserve regions.
Signed-off-by: Stefano Stabellini
Acked-
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Change make_memory_node to tak
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if there is no reg property or if nr_banks is reached. Le
Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.
Set min_depth to depth of the current node + 1 and replace the for
loop with a do/while loop to avoid scanning siblings of the initial node
passed as an argument.
We nee
flight 139986 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 18 guest-localmigrate/x10 fail REGR. vs. 139832
test-amd64-amd64-lib
flight 139996 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 140005 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139698
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.x
On 8/12/19 8:01 AM, Andrew Cooper wrote:
On 12/08/2019 15:53, George Dunlap wrote:
On 8/8/19 10:13 AM, Julien Grall wrote:
Hi Jan,
On 08/08/2019 10:04, Jan Beulich wrote:
On 08.08.2019 10:43, Andrew Cooper wrote:
On 08/08/2019 07:22, Jan Beulich wrote:
On 07.08.2019 21:41, Andrew Cooper wro
flight 140011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140011/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a0792697bc54e5472e2126c6fbff8031868426a9
baseline version:
ovmf 4053587347a4c68402c1f
On 05.08.19 00:48, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit
flight 140007 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 139876
test-amd64-i386-pa
On Thu, Aug 8, 2019 at 9:35 PM Roger Pau Monné wrote:
>
> On Thu, Aug 08, 2019 at 09:11:00PM +0800, Chuhong Yuan wrote:
> > Reference counters are preferred to use refcount_t instead of
> > atomic_t.
> > This is because the implementation of refcount_t can prevent
> > overflows and detect possible
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
Changes in v2:
- Also convert pendin
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
argument. drm_gem_fb_create_with_funcs does not modify its lst argument
(fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs
constant to protect
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.
Refuse to continue once we reach t
> -Original Message-
>
> === x86 ===
>
> * PV-IOMMU (v7)
> - Paul Durrant
>
Realistically I'm unlikely to get back to the hypercall interface any time
soon. There's just too much groundwork to lay, so probably better stop tracking
this for now.
Paul
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.
On Arm64, per the Image protocol [1], the state of the cache for BSS region
is not known because it is not part of the "loaded kernel image".
On Arm32, the
> -Original Message-
> From: Jan Beulich
> Sent: 07 August 2019 10:22
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Anthony Perard ;
> Roger Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; Konra
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Since we are at it, also switch the existing RESVD print to use unsigned
int.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- switch to unsigned
Chang
Arm64 provides instructions to load a PC-relative address, but with some
limitations:
- adr is enable to cope with +/-1MB
- adrp is enale to cope with +/-4GB but relative to a 4KB page
address
Because of that, the code requires to use 2 instructions to load any Xen
symbol. To make the c
flight 139980 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139980/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Sat, 10 Aug 2019, Julien Grall wrote:
> On Fri, 9 Aug 2019, 23:21 Stefano Stabellini, wrote:
> On Wed, 7 Aug 2019, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 06/08/2019 22:49, Stefano Stabellini wrote:
> > > As we parse the device tree in Xen, keep track of the
On Tue, Jul 30, 2019 at 03:10:13PM +0200, Laszlo Ersek wrote:
> Hi Anthony,
>
> On 07/29/19 17:39, Anthony PERARD wrote:
> > Patch series available in this git branch:
> > https://xenbits.xen.org/git-http/people/aperard/ovmf.git
> > br.platform-xen-pvh-v4
> >
> > Changes in v4:
> > - patch "Ovmf
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the position of
Xen in memory is not printed anymore. This can make difficult to debug
early code.
As Xen is not relocated anymore, we can add Xen as boot module before
calling boot_fdt_info(). With that, the function will print Xen module
in
flight 139952 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139876
Tests which are fa
The logic depends on being run on CPU0, and in IDLE context. Having this
explicitly identified allows for simplification of the whole S3 path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/power.c | 2 ++
1 file changed, 2 insertions(+
Hi,
this time a more detailed look. :)
> Subject: Re: [PATCH v8 01/28] linkage: new macros for assembler symbols
Patch subject needs a verb, like, for example:
"linkage: Introduce new macros for assembler symbols"
On Thu, Aug 08, 2019 at 12:38:27PM +0200, Jiri Slaby wrote:
> Introduce new C ma
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is imp
On Mon, 12 Aug 2019, Julien Grall wrote:
> On 09/08/2019 23:56, Stefano Stabellini wrote:
> > On Thu, 8 Aug 2019, Volodymyr Babchuk wrote:
> > > Hi Stefano,
> > >
> > > Stefano Stabellini writes:
> > >
> > > > Don't allow reserved-memory regions to be remapped into any guests,
> > > > until reser
> -Original Message-
> From: Jan Beulich
> Sent: 07 August 2019 11:32
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Alexandru Isaila
> ; Petre Pircalabu ;
> Razvan Cojocaru
> ; Andrew Cooper ; Roger
> Pau Monne
> ; VolodymyrBabchuk ; George
> Dunlap
> ; Ian
1 - 100 of 122 matches
Mail list logo
