flight 170520 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170520/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail like 170503
On Tue, May 17, 2022 at 04:24:25PM +, Maximilian Heyne wrote:
> Since commit 4d65adfcd119 ("x86: xen: insn: Decode Xen and KVM
> emulate-prefix signature"), objtool is able to correctly parse the
> prefixed instruction in xen_cpuid and emit correct orc unwind
> information. Hence, marking the
flight 170526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170525 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, May 18, 2022 12:01 AM
> To: Penny Zheng
> Cc: Wei Chen ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap ;
> Wei Liu ; xen-devel@lists.xenproject.org
>
On Tue, 17 May 2022, Jan Beulich wrote:
> Hmm. The present rules written down in docs/process/sending-patches.pandoc
> are a result of me having been accused of unduly stripping S-o-b (and maybe
> a few other) tags. If that was for a real reason (and not just because of
> someone's taste), how
flight 170524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Jan and Julien
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, May 18, 2022 12:11 AM
> To: Penny Zheng
> Cc: Wei Chen ; Andrew Cooper
> ; George Dunlap ;
> Julien Grall ; Stefano Stabellini ;
> Wei
> Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 1/6] xen:
flight 170522 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170521 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170514 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170514/
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
flight 170518 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170517 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
c/s cfc52148444f ("xen/domain: Reduce the quantity of initialisation for
system domains") removed the path in domain_create() which called
sched_init_domain() with CPUPOOLID_NONE for system domains.
Arguably, that changeset should have cleaned up this path too.
However, c/s 92ea9c54fc81
ARM folks: Please be rather more careful when exposing hypervisor internals to
arbitrary user input. Being domain_create, the fallout is unlikely to be an
security issue if it had gotten into a release, but Xen will definitely have
an unhappy time with unexpected scheduler state.
George/Nick:
Sadly, cpupool IDs are chosen by the caller, not assigned sequentially, so
this does need to have a full 32 bits of range.
Also leave a BUILD_BUG_ON() to catch more obvious ABI changes in the future.
Fixes: 92ea9c54fc81 ("arm/dom0less: assign dom0less guests to cpupools")
Signed-off-by: Andrew
> What I'm planning to do in the altera_edac notifier is:
>
> if (kdump_is_set)
> return;
Yes. That's what I think should happen.
-Tony
flight 170515 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 17/05/22 17:38, Jan Beulich wrote:
On 09.05.2022 14:24, Andrew Cooper wrote:
Spotted by Eclair MISRA scanner.
I'm sorry, but what exactly was it that the scanner spotted? It was
actually deliberate to introduce this file without guards. I'm of
the general opinion that (private) headers not
Hi,
On 08/03/2022 19:46, Vikram Garhwal wrote:
Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_lock().
Moving spin_lock to caller was done to prevent the concurrent access to
iommu_dt_device_is_assigned while doing add/remove/assign/deassign.
Signed-off-by: Vikram Garhwal
On 17/05/2022 14:02, Luck, Tony wrote:
>> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else
>> we run the code as-is? Does that make sense to you?
>
> The "skip" option sounds like it needs some special flag associated with
> an entry on the notifier chain. But there are
From: Oleksandr Tyshchenko
Add ability to allocate unpopulated DMAable (contiguous) pages
suitable for grant mapping into. This is going to be used by gnttab
code (see gnttab_dma_alloc_pages()).
TODO: There is a code duplication in fill_dma_pool(). Also pool
oparations likely need to be
From: Oleksandr Tyshchenko
Depends on CONFIG_XEN_UNPOPULATED_ALLOC. If enabled then unpopulated
DMAable (contiguous) pages will be allocated for grant mapping into
instead of ballooning out real RAM pages.
TODO: Fallback to real RAM pages if xen_alloc_unpopulated_dma_pages()
fails.
From: Oleksandr Tyshchenko
Hello all.
The purpose of this RFC patch series is to get feedback about supporting the
allocation
of DMAable pages by Linux's unpopulated-alloc.
The unpopulated-alloc feature has been enabled on Arm since the
extended-regions support
reached upstream. With that
flight 170513 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Vikram,
On 08/03/2022 19:46, Vikram Garhwal wrote:
Rename overlay_get_target() to fdt_overlay_target_offset() and remove static
function type.
This is done to get the target path for the overlay nodes which is very useful
in many cases. For example, Xen hypervisor needs it when applying
Hi Vikram,
On 08/03/2022 19:46, Vikram Garhwal wrote:
This is done to access fdt library function which are required for adding device
tree overlay nodes for dynamic programming of nodes.
Acked-by: Julien Grall
Signed-off-by: Vikram Garhwal
The tags usually are usually ordered
flight 170512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Michal,
On 17/05/2022 08:14, Michal Orzel wrote:
On 16.05.2022 12:19, Julien Grall wrote:
Hi Michal,
On 06/05/2022 10:42, Michal Orzel wrote:
Modify macros to evaluate all the arguments and make sure the arguments
are evaluated only once. Introduce following intermediate macros:
Hi,
On 17/05/2022 09:58, Bertrand Marquis wrote:
On 16 May 2022, at 18:02, Julien Grall wrote:
From: Julien Grall
Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
alloc/free" extended the checks in the buddy allocator to catch any
use of the helpers from context with
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the ESRT shall be stored in memory of type EfiBootServicesData. However,
memory of type EfiBootServicesData is considered general-purpose memory
by Xen,
> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else
> we run the code as-is? Does that make sense to you?
The "skip" option sounds like it needs some special flag associated with
an entry on the notifier chain. But there are other notifier chains ... so that
sounds messy to
On 17/05/2022 11:11, Petr Mladek wrote:
> [...]
>>> Then notifiers could make an informed choice on whether to deep dive to
>>> get all the possible details (when there is no kdump) or just skim the high
>>> level stuff (to maximize chance of getting a successful kdump).
>>>
>>> -Tony
>>
>> Good
On 17/05/2022 10:57, Petr Mladek wrote:
> [...]
--- a/drivers/misc/bcm-vk/bcm_vk_dev.c
+++ b/drivers/misc/bcm-vk/bcm_vk_dev.c
@@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
>>> [... snip ...]
>>> It seems to reset some
On 17/05/2022 10:28, Petr Mladek wrote:
> [...]
>>> Disagree here. I'm looping Google maintainers, so they can comment.
>>> (CCed Evan, David, Julius)
>>>
>>> This notifier is clearly a hypervisor notification mechanism. I've fixed
>>> a locking stuff there (in previous patch), I feel it's
Since commit 4d65adfcd119 ("x86: xen: insn: Decode Xen and KVM
emulate-prefix signature"), objtool is able to correctly parse the
prefixed instruction in xen_cpuid and emit correct orc unwind
information. Hence, marking the function as STACKFRAME_NON_STANDARD is
no longer needed.
This commit is
flight 170511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 10.05.2022 04:27, Penny Zheng wrote:
> @@ -2769,12 +2769,43 @@ int __init acquire_domstatic_pages(struct domain *d,
> mfn_t smfn,
>
> return 0;
> }
> +
> +/*
> + * Acquire a page from reserved page list(resv_page_list), when populating
> + * memory for static domain on runtime.
> + */
On 10.05.2022 04:27, Penny Zheng wrote:
> @@ -2762,6 +2767,12 @@ int __init acquire_domstatic_pages(struct domain *d,
> mfn_t smfn,
>
> return 0;
> }
> +#else
> +void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
> + bool need_scrub)
> +{
> +
On 17.05.2022 11:28, Julien Grall wrote:
> On 17/05/2022 09:21, Penny Zheng wrote:
@@ -2653,7 +2657,8 @@ void __init free_staticmem_pages(struct page_info
>>> *pg, unsigned long nr_mfns,
}
/* In case initializing page of static memory, mark it
On 17.05.2022 11:05, Penny Zheng wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -780,6 +780,11 @@ void __init setup_system_domains(void)
> * This domain owns I/O pages that are within the range of the page_info
> * array. Mappings occur at the priv of the caller.
>
flight 170510 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 17.05.2022 17:43, Roger Pau Monné wrote:
> On Tue, May 17, 2022 at 05:13:46PM +0200, Jan Beulich wrote:
>> On 17.05.2022 16:48, Roger Pau Monné wrote:
>>> On Tue, May 17, 2022 at 04:41:31PM +0200, Jan Beulich wrote:
On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
> ---
On Tue, May 17, 2022 at 05:13:46PM +0200, Jan Beulich wrote:
> On 17.05.2022 16:48, Roger Pau Monné wrote:
> > On Tue, May 17, 2022 at 04:41:31PM +0200, Jan Beulich wrote:
> >> On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
> >>> --- a/xen/drivers/char/ns16550.c
> >>> +++
On Tue, May 17, 2022 at 03:16:55PM +0200, Jan Beulich wrote:
> On 07.05.2022 06:26, Demi Marie Obenour wrote:
> > This would mean the allocation would need to be unconditional. Right
> > now, I avoid the allocation if it is not necessary.
>
> Hmm, I guess I don't see (taking into account also my
On 09.05.2022 15:53, Roger Pau Monné wrote:
> On Mon, May 09, 2022 at 01:24:09PM +0100, Andrew Cooper wrote:
>> This is undefined behaviour, because there is no _spin_lock_cb() in a
>> separate
>> translation unit (C11 6.7.4.11).
>>
>> Moreover, MISRA prohibits this construct because, in the case
On 09.05.2022 14:24, Andrew Cooper wrote:
> Spotted by Eclair MISRA scanner.
I'm sorry, but what exactly was it that the scanner spotted? It was
actually deliberate to introduce this file without guards. I'm of
the general opinion that (private) headers not to be included by
other headers (but
On 11/05/2022 08:45, Petr Mladek wrote:
> [...]
> DIE_OOPS and PANIC_NOTIFIER are from different enum.
> It feels like comparing apples with oranges here.
>
> IMHO, the proper way to unify the two notifiers is
> a check of the @self parameter. Something like:
>
> static int
On 10/05/2022 12:28, Petr Mladek wrote:
> [...]
> IMHO, the check of the @self parameter was the proper solution.
>
> "gisb_die_notifier" list uses @val from enum die_val.
> "gisb_panic_notifier" list uses @val from enum panic_notifier_val.
>
> These are unrelated types. It might easily break
On 17.05.2022 17:31, Roger Pau Monne wrote:
> Allow HVM guests access to MSR_VIRT_SPEC_CTRL if the platform Xen is
> running on has support for it. This requires adding logic in the
> vm{entry,exit} paths for SVM in order to context switch between the
> hypervisor value and the guest one. The
Hello,
The following series implements support for MSR_VIRT_SPEC_CTRL
(VIRT_SSBD) on different AMD CPU families.
Note that the support is added backwards, starting with the newer CPUs
that support MSR_SPEC_CTRL and moving to the older ones either using
MSR_VIRT_SPEC_CTRL or the SSBD bit in
Allow HVM guests access to MSR_VIRT_SPEC_CTRL if the platform Xen is
running on has support for it. This requires adding logic in the
vm{entry,exit} paths for SVM in order to context switch between the
hypervisor value and the guest one. The added handlers for context
switch will also be used
Use the logic to set shadow SPEC_CTRL values in order to implement
support for VIRT_SPEC_CTRL (signaled by VIRT_SSBD CPUID flag) for HVM
guests. This includes using the spec_ctrl vCPU MSR variable to store
the guest set value of VIRT_SPEC_CTRL.SSBD, which will be OR'ed with
any SPEC_CTRL values
Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
families use different bits in LS_CFG, so exposing VIRT_SPEC_CTRL.SSBD
allows for an unified way of exposing SSBD support to guests on AMD
hardware that's compatible
flight 170509 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 13.05.2022 16:33, George Dunlap wrote:
> Starting a new thread to make it clear that we’re discussing a wider policy
> here.
>
> This question is aimed at Jan and Andy in particular, as I think they’ve
> probably done the most of this; so I’m looking to them to find out what our
> “standard
On 17/05/2022 10:11, Petr Mladek wrote:
> [...]
>> You mentioned 2 cases:
>>
>> (a) Same notifier_list used in different situations;
>>
>> (b) Same *notifier callback* used in different lists;
>>
>> Mine is case (b), right? Can you show me an example of case (a)?
>
> There are many examples of
On 17.05.2022 16:48, Roger Pau Monné wrote:
> On Tue, May 17, 2022 at 04:41:31PM +0200, Jan Beulich wrote:
>> On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -1238,6 +1238,13 @@ pci_uart_config(struct ns16550
On 09.05.2022 21:55, Stefano Stabellini wrote:
> # Rule 8.6 " An identifier with external linkage shall have exactly one
> external definition"
>
> This one is meant to catch cases where there are 2 definitions for 1
> declaration:
>
> header.h:
> extern int hello;
>
> file1.c:
> int hello;
>
On 10.05.2022 12:15, Lin Liu wrote:
> --- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
> @@ -31,7 +31,6 @@ typedef uint64_t __be64;
>
> #define __BYTEORDER_HAS_U64__
> #define __TYPES_H__ /* xen/types.h guard */
> -#include
On 11.05.2022 16:21, Bertrand Marquis wrote:
>> On 11 May 2022, at 13:11, George Dunlap wrote:
>>> On May 11, 2022, at 9:34 AM, Julien Grall wrote:
>>> On 11/05/2022 07:30, Lin Liu （刘林） wrote:
On 10/05/2022 11:15, Lin Liu wrote:
> static inline void put_unaligned_be16(uint16_t val, void
On Tue, May 17, 2022 at 03:21:30PM +0200, Roger Pau Monne wrote:
> Under certain conditions guests can get the CPU stuck in an infinite
> loop without the possibility of an interrupt window to occur. This
> was the case with the scenarios described in XSA-156.
>
> Make use of the Notify VM Exit
On Tue, May 17, 2022 at 04:41:31PM +0200, Jan Beulich wrote:
> On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
> > --- a/xen/drivers/char/ns16550.c
> > +++ b/xen/drivers/char/ns16550.c
> > @@ -1238,6 +1238,13 @@ pci_uart_config(struct ns16550 *uart, bool_t
> > skip_amt, unsigned int idx)
>
On 17.05.2022 15:45, Roger Pau Monné wrote:
> On Tue, May 17, 2022 at 02:10:29PM +0200, Jan Beulich wrote:
>> On 09.05.2022 12:23, Roger Pau Monné wrote:
>>> On Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
On 03.05.2022 10:26, Roger Pau Monne wrote:
> ---
On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1238,6 +1238,13 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt,
> unsigned int idx)
> pci_conf_read8(PCI_SBDF(0, b, d, f),
>
Allow to map vcpu stats using acquire_resource().
Signed-off-by: Matias Ezequiel Vara Larsen
---
xen/common/domain.c | 42 +
xen/common/memory.c | 29 +
xen/common/sched/core.c | 5 +
Hello all,
The purpose of this RFC is to get feedback about a new acquire resource that
exposes vcpu statistics for a given domain. The current mechanism to get those
statistics is by querying the hypervisor. This mechanism relies on a hypercall
and holds the domctl spinlock during its execution.
Add a demostration tool that uses the stats_table resource to
query vcpu time for a DomU.
Signed-off-by: Matias Ezequiel Vara Larsen
---
tools/misc/Makefile| 5 +++
tools/misc/xen-stats.c | 83 ++
2 files changed, 88 insertions(+)
create mode 100644
On 16.05.2022 12:36, Roger Pau Monne wrote:
> Fixes: 5a211704e8 ('mwait-idle: prevent SKL-H boot failure when C8+C9+C10
> enabled')
> Signed-off-by: Roger Pau Monné
Thanks for spotting. I wonder whether we shouldn't mention the Linux
commit (654d08a42a56) which did this as a "side effect".
flight 170508 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170503 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170503/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 170492 pass in
170503
On Mon 2022-05-16 13:33:51, Guilherme G. Piccoli wrote:
> On 16/05/2022 13:18, Luck, Tony wrote:
> >> [...]
> > Would it be possible to have some global "kdump is configured + enabled"
> > flag?
> >
> > Then notifiers could make an informed choice on whether to deep dive to
> > get all the
On Mon 2022-05-16 12:06:17, Guilherme G. Piccoli wrote:
> Thanks for the review!
>
> I agree with the blinking stuff, I can rework and add all LED/blinking
> stuff into the loop list, it does make sense. I'll comment a bit in the
> others below...
>
> On 16/05/2022 11:01, Petr Mladek wrote:
> >>
On Tue, May 17, 2022 at 02:10:29PM +0200, Jan Beulich wrote:
> On 09.05.2022 12:23, Roger Pau Monné wrote:
> > On Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
> >> On 03.05.2022 10:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/cpuid.c
> >>> +++ b/xen/arch/x86/cpuid.c
> >>> @@
On Mon 2022-05-16 09:02:10, Evan Green wrote:
> On Mon, May 16, 2022 at 8:07 AM Guilherme G. Piccoli
> wrote:
> >
> > Thanks for the review!
> >
> > I agree with the blinking stuff, I can rework and add all LED/blinking
> > stuff into the loop list, it does make sense. I'll comment a bit in the
>
Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks for
evtchn delivery set up on a per-vCPU basis via
HVMOP_set_evtchn_upcall_vector.
is_hvm_pv_evtchn_vcpu() returning true is a condition for setting up
physical IRQ to event channel mappings.
The naming of the CPUID bit is quite
Under certain conditions guests can get the CPU stuck in an infinite
loop without the possibility of an interrupt window to occur. This
was the case with the scenarios described in XSA-156.
Make use of the Notify VM Exit mechanism, that will trigger a VM Exit
if no interrupt window occurs for a
Add support for enabling Bus Lock Detection on Intel systems. Such
detection works by triggering a vmexit, which is enough of a pause to
prevent a guest from abusing of the Bus Lock.
Add an extra perf counter to track the number of Bus Locks detected.
This is done because Bus Locks can also be
Hello,
Following series implements support for bus lock and VM notify.
Patches are not really dependent, but I've developed them together by
virtue of both features being in Intel Instructions Set Extensions PR
Chapter 9.
Thanks, Roger.
Roger Pau Monne (2):
x86/vmx: implement Bus Lock
On 10.05.2022 08:52, Michal Orzel wrote:
> Do you have any remarks related to the second patch in this series?
No, I have no further comments there.
Jan
On 07.05.2022 06:26, Demi Marie Obenour wrote:
> On Fri, May 06, 2022 at 12:59:05PM +0200, Jan Beulich wrote:
>> On 05.05.2022 07:38, Demi Marie Obenour wrote:
>>> @@ -1077,6 +1110,35 @@ static void __init efi_exit_boot(EFI_HANDLE
>>> ImageHandle, EFI_SYSTEM_TABLE *Syste
>>> if (
flight 170507 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Andrew,
> On 17 May 2022, at 14:01, Andrew Cooper wrote:
>
> On 06/05/2022 13:00, Luca Fancellu wrote:
>> 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
On Tue 2022-05-10 13:16:54, Guilherme G. Piccoli wrote:
> On 10/05/2022 12:16, Petr Mladek wrote:
> > [...]
> > Hmm, this looks like a hack. PANIC_UNUSED will never be used.
> > All notifiers will be always called with PANIC_NOTIFIER.
> >
> > The @val parameter is normally used when the same
On 17/05/2022 14:01, Andrew Cooper wrote:
> On 06/05/2022 13:00, Luca Fancellu wrote:
>> 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
On 17.05.22 15:01, Andrew Cooper wrote:
On 06/05/2022 13:00, Luca Fancellu wrote:
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
On 17/05/2022 07:58, Petr Mladek wrote:
> [...]
>> Thanks for the review Petr. Patch was already merged - my goal was to be
>> concise, i.e., a patch per driver / module, so the patch kinda fixes
>> whatever I think is wrong with the driver with regards panic handling.
>>
>> Do you think it worth
On 06/05/2022 13:00, Luca Fancellu wrote:
> 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
flight 170506 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 16.05.2022 10:01, Roger Pau Monné wrote:
> On Sun, May 08, 2022 at 10:34:43AM +0200, Jan Beulich wrote:
>> On 06.05.2022 17:35, Roger Pau Monné wrote:
>>> On Fri, May 06, 2022 at 03:31:12PM +0200, Roger Pau Monné wrote:
On Fri, May 06, 2022 at 02:56:56PM +0200, Jan Beulich wrote:
> On
On 09.05.2022 12:23, Roger Pau Monné wrote:
> On Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
>> On 03.05.2022 10:26, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -541,6 +541,9 @@ static void __init calculate_hvm_max_policy(void)
>>>
On Tue 2022-05-10 10:00:58, Guilherme G. Piccoli wrote:
> On 10/05/2022 09:14, Petr Mladek wrote:
> > [...]
> >> With that said, it's dangerous to use regular spinlocks in such path,
> >> as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple
> >> instances").
> >> This patch fixes
flight 170505 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170499 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170489
test-armhf-armhf-libvirt 16
Hi,
On 17/05/2022 09:21, Penny Zheng wrote:
Yes, I remembered that asynchronous is still on the to-do list for static
memory.
If it doesn't bother too much to you, I would like to ask some help on this
issue, ;).
I only knew basic knowledge on the scrubbing,
My kwnoledge on the scrubbing
From: Penny Zheng
To add statically shared memory nodes in Dom0, user shall put according
static shared memory configuration under /chosen node.
This commit adds shm-processing function process_shm in construct_dom0
to enable statically shared memory on Dom0.
Signed-off-by: Penny Zheng
This commit sets up shared memory foreign mapping for borrower domain.
If owner domain is the default dom_io, all shared domain are treated as
borrower domain.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v4 changes:
- no change
---
v3 change:
- use map_regions_p2mt instead
We expose the shared memory to the domU using the "xen,shared-memory-v1"
reserved-memory binding. See
Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
in Linux for the corresponding device tree binding.
To save the cost of re-parsing shared memory device tree configuration
1 - 100 of 118 matches
Mail list logo
