On 19.01.2023 19:19, Andrew Cooper wrote:
> On 19/01/2023 1:19 pm, Jan Beulich wrote:
>> Clearly within the for_each_vcpu() the vCPU of this loop is meant, not
>> the (loop invariant) one the fault occurred on.
>>
>> Signed-off-by: Jan Beulich
>
> Wow that's been broken for the entire lifetime of
On 19.01.23 22:11, Volodymyr Babchuk wrote:
There is a sequence of events that can lead to a permanently masked
event channel, because xen_irq_lateeoi() is newer called. This happens
when a backend receives spurious write event from a frontend. In this
case pvcalls_conn_back_write() returns early
On 18.01.23 13:22, David Woodhouse wrote:
From: David Woodhouse
When we don't use the per-CPU vector callback, we ask Xen to deliver event
channel interrupts as INTx on the PCI platform device. As such, it can be
shared with INTx on other PCI devices.
Set IRQF_SHARED, and make it return IRQ_HA
flight 175985 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175985/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
flight 175982 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175982/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-vhd 21 guest-start/debian.repeat fail in 175963 pass in
175982
test-amd64-amd64-x
On 19/01/2023 2:07 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
> new file mode 100644
> index 00..6f590e712b
> --- /dev/null
> +++ b/xen/arch/riscv/early_printk.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
On Fri, Jan 20, 2023 at 12:07 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Alistair
> ---
> Changes in V5:
> - Remove size_t from asm/types after rebase on top of the patch
> "include/types: move stddef.h-kind types to common heade
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> zeroeth_table_offset is not accessed by ARM_32.
> Also, when 32 bit physical addresses are used (ie ARM_PA_32=y), this
> causes an overflow.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from -
>
> v1 - Removed the duplicate declaration for
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> VTCR.T0SZ should be set as 0x20 to support 32bit IPA.
> Refer ARM DDI 0487I.a ID081822, G8-9824, G8.2.171, VTCR,
> "Virtualization Translation Control Register" for the bit descriptions.
>
> Signed-off-by: Ayan Kumar Halder
Acked-by: Stefano Stabel
flight 175977 qemu-mainline real [real]
flight 175990 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175977/
http://logs.test-lab.xenproject.org/osstest/logs/175990/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On Wed, 18 Jan 2023, Jan Beulich wrote:
> On 18.01.2023 12:57, Ayan Kumar Halder wrote:
> > Hi Jan,
> >
> > On 18/01/2023 08:50, Jan Beulich wrote:
> >> On 17.01.2023 18:43, Ayan Kumar Halder wrote:
> >>> --- a/xen/arch/arm/include/asm/types.h
> >>> +++ b/xen/arch/arm/include/asm/types.h
> >>> @@
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> In the subsequent patch, we introduce "CONFIG_ARM_PA_32" to support
> 32 bit physical addresses. Thus, the code specific to
> "Large Page Address Extension" (ie LPAE) should be enclosed within
> "ifndef CONFIG_ARM_PA_32".
>
> Refer xen/arch/arm/inclu
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
> SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
> writeq_relaxed_non_atomic() to write to it instead of invoking
> writel_relaxed() twice for lower half and upper half of the reg
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> dt_device_get_address() can accept u64 only for address and size. The
> various callers will use 'paddr_t' datatype for address and size.
> 'paddr_t' is currently defined as u64, but we may support u32 as well.
> Thus, we need an appropriate wrapper w
On Thu, 19 Jan 2023, Stefano Stabellini wrote:
> On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> > In future, we wish to support 32 bit physical address.
> > However, one can only read u64 values from the DT. Thus, we need to
> > typecast the values appropriately from u64 to paddr_t.
> >
> > devic
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> One should now be able to use 'paddr_t' to represent address and size.
> Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t.
>
> Signed-off-by: Ayan Kumar Halder
> ---
>
> Changes from -
>
> v1 - 1. Rebased the patch.
>
>
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> In future, we wish to support 32 bit physical address.
> However, one can only read u64 values from the DT. Thus, we need to
> typecast the values appropriately from u64 to paddr_t.
>
> device_tree_get_reg() should now be able to return paddr_t. This
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> bankbase, banksize and bankend are used to hold values of type 'unsigned
> long long'. This can be represented as 'uint64_t' instead of 'paddr_t'.
> This will ensure consistency with allocate_static_memory() (where we use
> 'uint64_t' for rambase and
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> 1. One should use 'PRIpaddr' to display 'paddr_t' variables.
> 2. One should use 'PRIx64' to display 'u64' in hex format. The current
> use of 'PRIpaddr' for printing PTE is buggy as this is not a physical
> address.
>
> Signed-off-by: Ayan Kumar Hal
On Mon, Jan 16 2023 at 15:55, Igor Mammedov wrote:
> "Srivatsa S. Bhat" wrote:
>> Fix this by preventing the use of mwait idle state in the vCPU offline
>> play_dead() path for any hypervisor, even if mwait support is
>> available.
>
> if mwait is enabled, it's very likely guest to have cpuidle
>
There is a sequence of events that can lead to a permanently masked
event channel, because xen_irq_lateeoi() is newer called. This happens
when a backend receives spurious write event from a frontend. In this
case pvcalls_conn_back_write() returns early and it does not clears the
map->write counter
On Fri, 06 Jan 2023 10:35:58 +, Paul Durrant wrote:
> Patch #2 was the original patch. It has been expended to a series in v6.
>
> Paul Durrant (2):
> KVM: x86/cpuid: generalize kvm_update_kvm_cpuid_base() and also
> capture limit
> KVM: x86/xen: update Xen CPUID Leaf 4 (tsc info) sub-
flight 175968 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175968/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow221 guest-start/debian.repeatfail like 175531
test-armhf-armhf-libvirt-qcow2 13 guest
On January 18, 2023 1:45:44 AM PST, Peter Zijlstra wrote:
>On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
>> The boot trampolines from trampoline_64.S have code flow like:
>>
>> 16bit BIOS SEV-ES 64bit EFI
>>
>> trampoline_start()
Doing so cannot work and should never happen.
Signed-off-by: Demi Marie Obenour
Tested-by: Marek Marczykowski-Górecki
---
drivers/firmware/efi/efi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index
b49fcde06ca0ff5347047666f38
Xen on x86 boots dom0 in EFI mode but without providing a memory map.
This means that some consistency checks we would like to perform on
configuration tables or other data structures in memory are not
currently possible. Xen does, however, expose EFI memory descriptor
info via a Xen hypercall, so
The ESRT can be parsed if EFI_PARAVIRT is enabled, even if EFI_MEMMAP is
not. Also allow the ESRT to be in reclaimable memory, as that is where
future Xen versions will put it.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Demi Marie Obenour
Tested-by: Marek Marczykowski-Górecki
---
As it turns out, Xen does not guarantee that EFI boot services data
regions in memory are preserved, which means that EFI configuration
tables pointing into such memory regions may be corrupted before the
dom0 OS has had a chance to inspect them.
This is causing problems for Qubes OS when it attem
This patch series fixes handling of EFI tables when running under Xen.
These fixes allow the ESRT to be loaded when running paravirtualized in
dom0, making the use of EFI capsule updates possible.
Demi Marie Obenour (5):
efi: memmap: Disregard bogus entries instead of returning them
efi: xen:
flight 175965 xen-unstable real [real]
flight 175984 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175965/
http://logs.test-lab.xenproject.org/osstest/logs/175984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 175967 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175967/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175736
test-armhf-armhf-libvirt-qcow2 15 saveres
On 19/01/2023 1:19 pm, Jan Beulich wrote:
> Clearly within the for_each_vcpu() the vCPU of this loop is meant, not
> the (loop invariant) one the fault occurred on.
>
> Signed-off-by: Jan Beulich
Wow that's been broken for the entire lifetime of the pagetable_dying op
0 3d5e6a3ff38 from 2010, but
flight 175966 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-bootfail REGR. vs. 173462
test-arm64-arm64-ex
On 19/01/2023 14:22, El Mesdadi Youssef ESK UILD7 wrote:
The support for xentrace on Arm has been added around Xen 4.12. So it should
work for Xen 4.14 (even though I don't recommend using older release).
Hello Julian,
First of all, thank you for the help. I contacted NXP support to get mor
On 19.01.2023 15:29, Jan Beulich wrote:
> On 19.01.2023 15:07, Oleksii Kurochko wrote:
>> In the patch "include/types: move stddef.h-kind types to common
>> header" [1] size_t was moved from to
>> so early_printk should be updated correspondingly.
>
> Hmm, this reads a little like that patch wou
Partial revert of c93bd0e6ea2a ("tmem: fix 32-on-64 support")
Since c492e19fdd05 ("xen: remove tmem from hypervisor"), this code
isn't used anymore.
Signed-off-by: Anthony PERARD
---
Notes:
v4:
- new patch
xen/tools/get-fields.sh | 57 +
1 file c
The get-fields.sh which generate all the include/compat/.xlat/*.h
headers is quite slow. It takes for example nearly 3 seconds to
generate platform.h on a recent machine, or 2.3 seconds for memory.h.
Rewriting the mix of shell/sed/python into a single python script make
the generation of those fil
`fields` and `extrafields` always all the parts of a sub-struct, so
when there is '}', there is always a '{' before it. Also, both are
lists.
Signed-off-by: Anthony PERARD
---
xen/tools/compat-xlat-header.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/tools/compat
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-include-rework-v4
v4:
- new patch removing get_typedefs() from the existing script
(and thus also removing it from the new script)
- Adding some optimisation, mainly p
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Penny Zheng
The start-of-day Xen MPU memory region layout shall be like as follows:
xen_mpumap[0] : Xen text
xen_mpumap[1] : Xen read-only data
xen_mpumap[2] : Xen read-only after init data
xen_mpumap[3] : Xen read-write data
xen_mpumap[
flight 175981 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175981/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51411435d559c55eaf38c02baf5d76da78bb658d
baseline version:
ovmf 18df11da8c14e48b6e4a9
On 19.01.2023 15:07, Oleksii Kurochko wrote:
> In the patch "include/types: move stddef.h-kind types to common
> header" [1] size_t was moved from to
> so early_printk should be updated correspondingly.
Hmm, this reads a little like that patch would introduce a build
issue (on Arm), but accordin
> The support for xentrace on Arm has been added around Xen 4.12. So it should
> work for Xen 4.14 (even though I don't recommend using older release).
Hello Julian,
First of all, thank you for the help. I contacted NXP support to get more
information about how to get the newest version of Xen
Hi,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
Xen defines some global configuration macros for Arm in
config.h. We still want to use it for Armv8-R systems, but
there are some address related macros that are defined for
MMU systems. These macros will not be used by MPU systems,
Ad
From: Bobby Eshleman
Originally SBI implementation for Xen was introduced by
Bobby Eshleman but it was removed
all the stuff for simplicity except SBI call for putting
character to console.
The patch introduces sbi_putchar() SBI call which is necessary
to implement initial early_printk.
Signe
Add check if there is a message 'Hello from C env' presents
in log file to be sure that stack is set and C part of early printk
is working.
Signed-off-by: Oleksii Kurochko
Acked-by: Stefano Stabellini
Reviewed-by: Alistair Francis
---
Changes in V5:
- Nothing changed
---
Changes in V4:
- No
Because printk() relies on a serial driver (like the ns16550 driver)
and drivers require working virtual memory (ioremap()) there is not
print functionality early in Xen boot.
The patch introduces the basic stuff of early_printk functionality
which will be enough to print 'hello from C environment
In the patch "include/types: move stddef.h-kind types to common
header" [1] size_t was moved from to
so early_printk should be updated correspondingly.
[1]
https://lore.kernel.org/xen-devel/5a0a9e2a-c116-21b5-8081-db75fe417...@suse.com/
Signed-off-by: Oleksii Kurochko
---
xen/include/xen/ear
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Remove size_t from asm/types after rebase on top of the patch
"include/types: move stddef.h-kind types to common header" [1].
- All other types were back as they are used in and
in xen/common.
---
Changes in V4:
The patch series introduces the following:
- the minimal set of headers and changes inside them.
- SBI (RISC-V Supervisor Binary Interface) things necessary for basic
early_printk implementation.
- things needed to set up the stack.
- early_printk() function to print only strings.
- RISC-V smoke
flight 175963 qemu-upstream-unstable real [real]
flight 175980 qemu-upstream-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175963/
http://logs.test-lab.xenproject.org/osstest/logs/175980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests
Hi Juergen,
On 18/01/2023 09:50, Juergen Gross wrote:
Today check_store() is only testing the correctness of the node tree.
Add verification of the accounting data (number of nodes) and correct
the data if it is wrong.
Do the initial check_store() call only after Xenstore entries of a
live upd
Hi Juergen,
On 18/01/2023 09:50, Juergen Gross wrote:
Make the xenstored internal trace configurable by adding classes
which can be switched on and off independently from each other.
Define the following classes:
- obj: Creation and deletion of interesting "objects" (watch,
transaction, con
Hi Juergen,
On 18/01/2023 09:50, Juergen Gross wrote:
Letting hashtable_remove() return the value of the removed element is
not used anywhere in Xenstore, and it conflicts with a hashtable
created specifying the HASHTABLE_FREE_VALUE flag.
So just drop returning the value.
This of course requir
Hi Juergen,
On 18/01/2023 09:50, Juergen Gross wrote:
Rework the interface and the internals of the per-domain node
accounting:
- rename the functions to domain_nbentry_*() in order to better match
the related counter name
- switch from node pointer to domid as interface, as all nodes have
On 19.01.2023 13:45, Oleksii Kurochko wrote:
> The patch series introduces the following:
> - the minimal set of headers and changes inside them.
> - SBI (RISC-V Supervisor Binary Interface) things necessary for basic
> early_printk implementation.
> - things needed to set up the stack.
> - early
Neither p2m_mmio_dm nor the types p2m_is_readonly() checks for are
applicable to PV; specifically get_gfn() won't ever return such a type
for PV domains. Adjacent to those checks is yet another is_hvm_...()
one. With that block made conditional, another conditional block near
the end of the functio
Clearly within the for_each_vcpu() the vCPU of this loop is meant, not
the (loop invariant) one the fault occurred on.
Signed-off-by: Jan Beulich
---
Quitle likely this mistake would have been avoided if the function scope
variable was named "curr", leaving "v" available for purposes likethe
one
On Mon, Jan 16, 2023 at 03:25:35PM +0100, Peter Zijlstra wrote:
> Per the comment it is important to call sev_verify_cbit() before the
> first RET instruction, this means we can delay calling this until more
Make that "... this means that this can be delayed until... "
And I believe this is not a
1: fix PAE check for top-level table unshadowing
2: mark more of sh_page_fault() HVM-only
Jan
Hi Andrew,
> Maybe we want to make it CC-BY-4 to require people to reference back to
> the canonical upstream ?
Thanks for your response, can we have a more declarative statement on
the license from your end
and also can you please provide your acknowledgement over the usage of
Xen security data i
flight 175971 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175971/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 18df11da8c14e48b6e4a90fb0b5befb1c243070a
baseline version:
ovmf 426efcc37492da4ebd867
On 19/01/2023 10:50 am, Jan Beulich wrote:
> On 18.01.2023 19:21, Anthony PERARD wrote:
>> On Tue, Jan 17, 2023 at 05:21:32PM +, Andrew Cooper wrote:
>>> On 16/01/2023 6:10 pm, Anthony PERARD wrote:
+def get_typedefs(tokens):
+level = 1
+state = 0
+typedefs = []
On 18.01.2023 19:21, Anthony PERARD wrote:
> On Tue, Jan 17, 2023 at 05:21:32PM +, Andrew Cooper wrote:
>> On 16/01/2023 6:10 pm, Anthony PERARD wrote:
>>> +def get_typedefs(tokens):
>>> +level = 1
>>> +state = 0
>>> +typedefs = []
>>
>> I'm pretty sure typedefs actually wants to be
On 13/01/2023 05:28, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Penny Zheng
The start-of-day Xen MPU memory region layout shall be like
Flush existing debug messages before writing an error to stderr. stderr
is usually unbuffered and stdout is usually buffered. This results in
odd looking output when an error occurs and both stderr/stdout are
printed on the same console/file. More precisely, the error message is
printed in the mid
From: Raphael Ning
Not all .o files generated by the Xen build need to be passed to
create-diff-object for analysis. The latest example is:
Run create-diff-object on xen/arch/x86/efi/buildid.o
Open base
/usr/libexec/livepatch-build-tools/create-diff-object: ERROR: buildid.o:
kpatch_create_se
From: Stanislav Uschakow
This fixes an issue when stacking multiple hotpatches modifying the same
function when there is also an internal call to that function within
these patches.
Two hotpatches touching the same subset of functions can result in a
situation where the second hotpatch is loaded
From: Raphael Ning
Fix a bug in create_patch() where cp, strip, etc. will fail if the new
object file introduced by the patch is located in a new subdirectory:
DEBUG: cp: cannot create regular file `output/xen/common/lu/lu.o': No such
file or directory
DEBUG: strip: 'output/xen/common/lu/lu.o
Small series of unrelated patches currently used by AWS fork of
livepatch-build-tools but not present upstream. Symbol alias patch is only
relevant for the case of stacking multiple patches and thus may be of no use to
xen in general but still submitting it for extra visibility.
Michael Kurth (1):
On 18.01.2023 19:21, Julien Grall wrote:
> On 06/09/2022 11:32, Jan Beulich wrote:
>> On 31.08.2022 16:10, Volodymyr Babchuk wrote:
>>> Hello,
>>>
>>> This is yet another take to a PCI locking rework. This approach
>>> was suggest by Jan Beulich who proposed to use a reference
>>> counter to contro
Hello all,
On 13/01/2023 13:24, Ayan Kumar Halder wrote:
> Currently, kernel_uimage_probe() does not read the load/entry point address
> set in the uImge header. Thus, info->zimage.start is 0 (default value). This
> causes, kernel_zimage_place() to treat the binary (contained within uImage)
> as p
flight 175962 qemu-mainline real [real]
flight 175975 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175962/
http://logs.test-lab.xenproject.org/osstest/logs/175975/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
73 matches
Mail list logo
