On 11.04.2021 04:12, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-armhf-armhf-xl-multivcpu
> testid guest-start/debian.repeat
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tre
On 09.04.2021 23:01, Ankur Arora wrote:
> On 2021-04-08 11:38 p.m., Jan Beulich wrote:
>> On 09.04.2021 08:08, Ankur Arora wrote:
>>> On 4/8/2021 6:58 AM, Jan Beulich wrote:
The present copy_page() is the way it is because of the desire to
avoid disturbing the cache. The effect of REP STO
flight 161037 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 12.04.2021 08:28, Juergen Gross wrote:
> The backport of upstream patch 25da4618af240fbec61 ("xen/events: don't
> unmask an event channel when an eoi is pending") introduced a
> regression for stable kernels 5.10 and older: setting IRQ affinity for
> IRQs related to interdomain events would no l
On Fri, Nov 27, 2020 at 05:54:57PM +0100, Jan Beulich wrote:
> On x86, idle and other system domains are implicitly PV. While I
> couldn't spot any cases where this is actively a problem, some cases
> required quite close inspection to be certain there couldn't e.g. be
> some ASSERT_UNREACHABLE() t
On 12.04.21 11:32, Jan Beulich wrote:
On 12.04.2021 08:28, Juergen Gross wrote:
The backport of upstream patch 25da4618af240fbec61 ("xen/events: don't
unmask an event channel when an eoi is pending") introduced a
regression for stable kernels 5.10 and older: setting IRQ affinity for
IRQs related
On 09.04.2021 23:43, Boris Ostrovsky wrote:
>
> On 4/7/21 10:37 AM, Jan Beulich wrote:
>> When multiple PCI devices get assigned to a guest right at boot, libxl
>> incrementally populates the backend tree. The writes for the first of
>> the devices trigger the backend watch. In turn xen_pcibk_setu
On 12.04.2021 11:39, Juergen Gross wrote:
> On 12.04.21 11:32, Jan Beulich wrote:
>> Possibly related, but first of all seeing the redundancy between
>> eoi_pirq() and ack_dynirq(): Wouldn't it make sense to break out the
>> common part into a helper? (Really the former could simply call the
>> lat
On 09.04.2021 23:45, Boris Ostrovsky wrote:
>
> On 4/7/21 10:37 AM, Jan Beulich wrote:
>> There's no point in comparing SBDF - we can simply compare the struct
>> pci_dev pointers. If they weren't the same for a given device, we'd have
>> bigger problems from having stored a stale pointer.
>>
>> S
On 12.04.2021 11:34, Roger Pau Monné wrote:
> On Fri, Nov 27, 2020 at 05:54:57PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/dom0_build.c
>> +++ b/xen/arch/x86/dom0_build.c
>> @@ -568,7 +568,7 @@ int __init construct_dom0(struct domain
>>
>> if ( is_hvm_domain(d) )
>> rc = dom0_
Ian Jackson writes ("Re: Commit moratorium on staging-4.15"):
> Please hold off pushing to staging-4.15 until advised. I need to
> do post-release updates do the version number and README and so on. I
> plan to do that on Monday.
This is now done. Backports may be pushed to staging-4.15 by the
On 12.04.2021 12:12, Ian Jackson wrote:
> Ian Jackson writes ("Re: Commit moratorium on staging-4.15"):
>> Please hold off pushing to staging-4.15 until advised. I need to
>> do post-release updates do the version number and README and so on. I
>> plan to do that on Monday.
>
> This is now done.
Hi Stefano,
> On 10 Apr 2021, at 1:27 am, Stefano Stabellini wrote:
>
> On Tue, 6 Apr 2021, Stefano Stabellini wrote:
>> On Mon, 5 Apr 2021, Julien Grall wrote:
>>> On 26/01/2021 22:58, Stefano Stabellini wrote:
Hi all,
>>>
>>> Hi Stefano,
>>>
This series introduces support for the gene
While part of the original AMD64 spec, Long Mode Segment Limit Enable was a
feature not picked up by Intel, and therefore didn't see much adoption in
software. AMD have finally dropped the feature from hardware, and allocated a
CPUID bit to indicate its absence.
Xen has never supported the featur
The address of this page is used by the CPU only to recognize when to
access the virtual APIC page instead. No accesses would ever go to this
page. It only needs to be present in the (CPU) page tables so that
address translation will produce its address as result for respective
accesses.
By making
Some of them have entries with stale comments. Rather than correcting
these comments, re-arrange how these arrays get populated, shrinking
their sizes at the same time (by omitting trailing NULL entries: Use
dedicated element initializers, serving the purpose of what the
comments did so far. This t
It's now unused after commit 28fb8cf323dd93f59a9c851c93ba9b79de8b1c4e.
Fixes: 28fb8cf323d ('x86/iommu: remove code to fetch MSI message from remap
table')
Signed-off-by: Roger Pau Monné
---
xen/include/xen/iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/xen/iommu.h b/xen/
On 12.04.2021 12:22, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -456,6 +456,12 @@ static void __init calculate_hvm_max_policy(void)
> __set_bit(X86_FEATURE_X2APIC, hvm_featureset);
>
> /*
> + * We don't support EFER.LMSLE at all. AMD has dro
On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
> MSI related code in the "passthrough/pci.c” file is not useful for ARM
> when MSI interrupts are injected via GICv3 ITS.
>
> Therefore introducing the new flag CONFIG_PCI_MSI_INTERCEPT to gate the
> MSI code for ARM in common code. Als
On 12.04.2021 12:42, Roger Pau Monne wrote:
> It's now unused after commit 28fb8cf323dd93f59a9c851c93ba9b79de8b1c4e.
>
> Fixes: 28fb8cf323d ('x86/iommu: remove code to fetch MSI message from remap
> table')
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
This is the v2 of xen/arm: Prevent Dom0 to be loaded when using dom0less
previously pushed.
The aim of this serie is to prevent the creation and run of the domain 0 (Dom0)
when the system configuration to be used is dom0less, that is when the device
tree declares at least one domU and no Dom0.
Ch
The function is_hardware_domain() returns true if the
hardware_domain and the passed domain is NULL, here we
add a check to return false if there is no hardware_domain.
Among the common and arm codebase there are few cases where
the hardware_domain variable is checked to see if the current
domain
Move dom0 creation and start from setup.c to domain_build.c
on a dedicate function.
Signed-off-by: Luca Fancellu
---
v3 changes:
- move create_dom0 function after construct_dom0 and
make construct_dom0 static
---
xen/arch/arm/domain_build.c | 38 -
xen/arch/
This patch adds a comment in create_domUs() right before
domain_create() to explain the importance of the pre-increment
operator on the variable max_init_domid, to ensure that the
domid 0 is allocated only during start_xen() function by the
create_dom0() and not on any other possible code path to t
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
---
v3 changes:
- Rephrase documentation
---
docs/features/dom0less.pandoc | 7 +++---
xen/arch/arm/s
flight 160980 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On 12.04.2021 12:52, Luca Fancellu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1022,6 +1022,9 @@ static always_inline bool is_hardware_domain(const
> struct domain *d)
> if ( IS_ENABLED(CONFIG_PV_SHIM_EXCLUSIVE) )
> return false;
>
> +if ( !d )
On 12.04.2021 12:49, Roger Pau Monné wrote:
> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -1411,6 +1411,70 @@ void __init early_msi_init(void)
>> return;
>> }
>>
>> +int alloc_pci_msi(struct pci_dev *pdev)
>
Not having direct_mmio (used only once anyway) as a local variable gets
the epte_get_entry_emt() invocation here in better sync with the other
ones. While at it also reduce ipat's scope.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -677,8 +677,6 @
flight 161033 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161033/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 97336fdee4f9847e164639f06616ce1139ef9a15
baseline version:
ovmf efa7f4df0f3b9e70d49dc
Put it next to another boolean, so they will "share" the subsequent
padding hole.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -113,15 +113,15 @@ struct hvm_domain {
* mtrr/pat between vcpus is not the same, set is_in_uc_mode
On 12/04/2021 12:37, Jan Beulich wrote:
> Put it next to another boolean, so they will "share" the subsequent
> padding hole.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 12/04/2021 11:48, Jan Beulich wrote:
> On 12.04.2021 12:22, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -456,6 +456,12 @@ static void __init calculate_hvm_max_policy(void)
>> __set_bit(X86_FEATURE_X2APIC, hvm_featureset);
>>
>> /*
>> + *
On Mon, Apr 12, 2021 at 01:33:50PM +0200, Jan Beulich wrote:
> Not having direct_mmio (used only once anyway) as a local variable gets
> the epte_get_entry_emt() invocation here in better sync with the other
> ones. While at it also reduce ipat's scope.
>
> Signed-off-by: Jan Beulich
Reviewed-by
The aspect of the function the second patch here changes has been
puzzling me for many years. I finally thought I ought to make an
attempt at reducing this to just a single get_page_from_l1e()
invocation. The first patch mainly helps readability (of the code
in general as well as the second patch).
There's little point in doing multiple mfn_to_page() or page_get_owner()
on all the same MFN. Calculate them once at the start of the function.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/set.c
+++ b/xen/arch/x86/mm/shadow/set.c
@@ -89,25 +89,27 @@ shadow_get_page_from_l1e(shadow_l1e
Trying get_page_from_l1e() up to three times isn't helpful; in debug
builds it may lead to log messages mking things look as if there was a
problem somewhere. And there's no need to have more than one try: The
function can only possibly succeed for one domain passed as 3rd
argument (unless the page
On 12.04.2021 13:39, Andrew Cooper wrote:
> On 12/04/2021 11:48, Jan Beulich wrote:
>> On 12.04.2021 12:22, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -456,6 +456,12 @@ static void __init calculate_hvm_max_policy(void)
>>> __set_bit(X86_FEATURE_X2
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules run before X
We are going to want to change the value of PcdFSBClock at run time in
OvmfXen, so move it to the PcdsDynamic section.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
Reviewed-by: Liming Gao
---
Notes:
CC: Michael D Kinney
Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v3
Changes in v3:
- typos and codying style
Changes in v2:
- main change is to allow mapping of Xen pages outside of the RAM
see patch: "OvmfPkg/XenPlatformPei: Map extra physical address
To avoid nasm generating a warning, replace the macro by the value
expected to be stored in eax.
Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds
Reported-by: Laszlo Ersek
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +-
Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.
While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G gues
We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v2:
- fix case
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines
We are going to use the page table structure in yet another place,
collect the types and macro that can be used from another module
rather than making yet another copy.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD
Acked-by: Tom Lendacky
---
Notes:
C
flight 161051 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161051/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> On 12 Apr 2021, at 12:03, Jan Beulich wrote:
>
> On 12.04.2021 12:52, Luca Fancellu wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -1022,6 +1022,9 @@ static always_inline bool is_hardware_domain(const
>> struct domain *d)
>> if ( IS_ENABLED(CONFIG_PV_SHIM
Since it was brought up in the discussion of v1: I think the end
goal is to be for mm/p2m.c to become a HVM-only file. Any "wrappers"
also trying to take care of !paging_mode_translate() guests ought to
be moved elsewhere. To see what actually still needs taking care of,
incrementally extending the
Extend a respective #ifdef from inside set_typed_p2m_entry() to around
all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety
check path.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1260,6 +1260,8 @@ int p2m_finish_type_change(struct d
Mirror the "translated" check the functions do to do_domctl(), allowing
the calls to be DCEd by the compiler. Add ASSERT_UNREACHABLE() to the
original checks.
Also arrange for {set,clear}_mmio_p2m_entry() and
{set,clear}_identity_p2m_entry() to respectively live next to each
other, such that clear
Exclude functions using them from !HVM builds, thus making it possible
to exclude the hooks as well. Also cover the already unused
memory_type_changed hook while inserting the #ifdef in the struct.
While no respective check was there, I can't see how
XEN_DOMCTL_set_broken_page_p2m could have been
Generally all of this is dead code anyway, but there's a caller of
guest_iommu_add_ppr_log(), and the code itself calls
p2m_change_type_one(), which is about to become HVM-only. Hence this
code, short of deleting it altogether, needs to become properly HVM-
only as well.
Signed-off-by: Jan Beulich
As is the adjacent ga_to_gfn() one as well as paging_gva_to_gfn().
Signed-off-by: Jan Beulich
---
v2: Fix !SHADOW_PAGING && !HVM build.
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1793,7 +1793,6 @@ void np2m_schedule(int dir)
p2m_unlock(p2m);
}
}
-#endif
unsigne
Exclude functions using them from !HVM builds, thus making it possible
to exclude the hooks as well.
By moving an #endif in p2m.c (instead of introducing yet another one)
p2m_{get,set}_ioreq_server() get excluded for !HVM builds as well.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x8
Exclude functions involved in its use from !HVM builds, thus making it
possible to exclude the hook as well.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -1173,8 +1173,8 @@ void p2m_pt_init(struct p2m_domain *p2m)
{
p2m->set_entry
By excluding the file from being built for !HVM, #ifdef-ary can be
removed from it.
The new HVM dependency on the Kconfig option is benign for Arm.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -15,7 +15,6 @@ config X86
select HAS_FAST_
With the hooks no longer needing setting, p2m_pt_init() degenerates to
(about) nothing when !HVM. As a result, p2m-pt.c doesn't need building
anymore in this case, as long as p2m_pt_init() has proper surrogates put
in place.
Unfortunately this means some new #ifdef-ary in p2m.c, but the mid-term
p
While doing so, make the option dependent upon HVM, which really is the
main purpose of the change.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -15,7 +15,6 @@ config X86
select HAS_FAST_MULTIPLY
select HAS_IOPORTS
selec
Move respective shadow code to its HVM-only source file, thus making it
possible to exclude the hooks as well. This then shows that
shadow_p2m_init() also isn't needed in !HVM builds.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/commo
Combine two HVM-specific sections in two cases (i.e. going from four of
them to just two). Make defer_nested_flush bool and HVM-only, moving it
next to other nested stuff. Move default_access up into a padding hole.
When moving them anyway, also adjust comment style.
Signed-off-by: Jan Beulich
-
On Mon, Apr 12, 2021 at 10:10 AM Jan Beulich wrote:
>
> By excluding the file from being built for !HVM, #ifdef-ary can be
> removed from it.
>
> The new HVM dependency on the Kconfig option is benign for Arm.
>
> Signed-off-by: Jan Beulich
Acked-by: Tamas K Lengyel
On Mon, Apr 12, 2021 at 10:12 AM Jan Beulich wrote:
>
> While doing so, make the option dependent upon HVM, which really is the
> main purpose of the change.
IMHO it would be better to just remove this dead code altogether.
Tamas
On 12.04.2021 15:58, Luca Fancellu wrote:
>
>
>> On 12 Apr 2021, at 12:03, Jan Beulich wrote:
>>
>> On 12.04.2021 12:52, Luca Fancellu wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -1022,6 +1022,9 @@ static always_inline bool is_hardware_domain(const
>>> stru
On 12.04.2021 17:12, Jan Beulich wrote:
CAUTION: This email originated from outside of our organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
While doing so, make the option dependent upon HVM, which really is the
main purpose
On 12.04.2021 17:18, Tamas K Lengyel wrote:
CAUTION: This email originated from outside of our organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Mon, Apr 12, 2021 at 10:12 AM Jan Beulich wrote:
While doing so, make the o
On 12.04.2021 17:10, Jan Beulich wrote:
CAUTION: This email originated from outside of our organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
By excluding the file from being built for !HVM, #ifdef-ary can be
removed from it.
On Mon, Apr 12, 2021 at 12:07:12PM +0200, Jan Beulich wrote:
> On 12.04.2021 11:34, Roger Pau Monné wrote:
> > On Fri, Nov 27, 2020 at 05:54:57PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/dom0_build.c
> >> +++ b/xen/arch/x86/dom0_build.c
> >> @@ -568,7 +568,7 @@ int __init construct_dom0(st
While part of the original AMD64 spec, Long Mode Segment Limit was a feature
not picked up by Intel, and therefore didn't see much adoption in software.
AMD have finally dropped the feature from hardware, and allocated a CPUID bit
to indicate its absence.
Xen has never supported the feature for gu
When setting the highest pfn used in the guest, don't subtract 1 from
the value read from the shared_info data. The value read already is
the correct pfn.
Fixes: 91e204d37f449 ("libxc: try to find last used pfn when migrating")
Signed-off-by: Juergen Gross
---
This is a backport candidate
---
to
There are some corners left which don't support the not so very new
linear p2m list of pv guests, which has been introduced in Linux kernel
3.19 and which is mandatory for non-legacy versions of Xen since kernel
4.14.
This series adds support for the linear p2m list where it is missing
(colo suppo
The core of a pv linux guest produced via "xl dump-core" is not usable
as since kernel 4.14 only the linear p2m table is kept if Xen indicates
it is supporting that. Unfortunately xc_core_arch_map_p2m() is still
supporting the 3-level p2m tree only.
Fix that by copying the functionality of map_p2m
Instead of open coding the mapping of the p2m list use the already
existing xc_core_arch_map_p2m() call, especially as the current code
does not support guests with the linear p2m map. It should be noted
that this code is needed for colo/remus only.
Switching to xc_core_arch_map_p2m() drops the ne
There are some definitions which are used in libxenguest only now.
Move them from libxenctrl over to libxenguest.
Remove an unused macro.
Signed-off-by: Juergen Gross
---
tools/libs/ctrl/xc_private.h | 32
tools/libs/guest/xg_core.h | 2 +-
tools/libs/gue
The guest suspend functionality is already part of libxenguest. Move
the resume functionality from libxenctrl to libxenguest, too.
Signed-off-by: Juergen Gross
---
tools/include/xenctrl.h | 63 ---
tools/include/xenguest.h | 62 +
The functionality in xc_core* should be part of libxenguest instead
of libxenctrl. Users are already either in libxenguest, or in xl.
There is one single exception: xc_core_arch_auto_translated_physmap()
is being used by xc_domain_memory_mapping(), which is used by qemu.
So leave the xc_core_arch_a
On 12.04.2021 16:49, Roger Pau Monné wrote:
> On Mon, Apr 12, 2021 at 12:07:12PM +0200, Jan Beulich wrote:
>> On 12.04.2021 11:34, Roger Pau Monné wrote:
>>> On Fri, Nov 27, 2020 at 05:54:57PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@
On 12.04.2021 17:06, Andrew Cooper wrote:
> While part of the original AMD64 spec, Long Mode Segment Limit was a feature
> not picked up by Intel, and therefore didn't see much adoption in software.
> AMD have finally dropped the feature from hardware, and allocated a CPUID bit
> to indicate its ab
On Mon, Apr 12, 2021 at 12:40:48PM +0200, Jan Beulich wrote:
> The address of this page is used by the CPU only to recognize when to
> access the virtual APIC page instead. No accesses would ever go to this
> page. It only needs to be present in the (CPU) page tables so that
> address translation w
On Mon, Apr 12, 2021 at 05:24:41PM +0200, Jan Beulich wrote:
> On 12.04.2021 16:49, Roger Pau Monné wrote:
> > On Mon, Apr 12, 2021 at 12:07:12PM +0200, Jan Beulich wrote:
> >> On 12.04.2021 11:34, Roger Pau Monné wrote:
> >>> On Fri, Nov 27, 2020 at 05:54:57PM +0100, Jan Beulich wrote:
> ---
On 12.04.2021 17:40, Roger Pau Monné wrote:
> On Mon, Apr 12, 2021 at 05:24:41PM +0200, Jan Beulich wrote:
>> On 12.04.2021 16:49, Roger Pau Monné wrote:
>>> On Mon, Apr 12, 2021 at 12:07:12PM +0200, Jan Beulich wrote:
On 12.04.2021 11:34, Roger Pau Monné wrote:
> On Fri, Nov 27, 2020 at 0
On 4/12/21 5:44 AM, Jan Beulich wrote:
>
>> It also looks a bit odd that adding a device is now viewed as a
>> reconfiguration. It seems to me that xen_pcibk_setup_backend() and
>> xen_pcibk_reconfigure() really should be merged --- initialization code for
>> both looks pretty much the same.
>
flight 161015 xen-4.12-testing real [real]
flight 161058 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161015/
http://logs.test-lab.xenproject.org/osstest/logs/161058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 4/12/21 5:50 AM, Jan Beulich wrote:
> On 09.04.2021 23:45, Boris Ostrovsky wrote:
>> On 4/7/21 10:37 AM, Jan Beulich wrote:
>>> There's no point in comparing SBDF - we can simply compare the struct
>>> pci_dev pointers. If they weren't the same for a given device, we'd have
>>> bigger problems
From: Lv Yunlong
[ Upstream commit 52762efa2b256ed1c5274e5177cbd52ee11a2f6a ]
In function displback_changed, has the call chain
displback_connect(front_info)->xen_drm_drv_init(front_info).
We can see that drm_info is assigned to front_info->drm_info
and drm_info is freed in fail branch in xen_dr
From: Lv Yunlong
[ Upstream commit 52762efa2b256ed1c5274e5177cbd52ee11a2f6a ]
In function displback_changed, has the call chain
displback_connect(front_info)->xen_drm_drv_init(front_info).
We can see that drm_info is assigned to front_info->drm_info
and drm_info is freed in fail branch in xen_dr
Hi Roger,
> On 12 Apr 2021, at 11:49 am, Roger Pau Monné wrote:
>
> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
>> MSI related code in the "passthrough/pci.c” file is not useful for ARM
>> when MSI interrupts are injected via GICv3 ITS.
>>
>> Therefore introducing the new flag
> On 12 Apr 2021, at 15:22, Jan Beulich wrote:
>
> On 12.04.2021 15:58, Luca Fancellu wrote:
>>
>>
>>> On 12 Apr 2021, at 12:03, Jan Beulich wrote:
>>>
>>> On 12.04.2021 12:52, Luca Fancellu wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1022,6 +1022,
Hi Jan,
> On 12 Apr 2021, at 12:28 pm, Jan Beulich wrote:
>
> On 12.04.2021 12:49, Roger Pau Monné wrote:
>> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
>>> --- a/xen/arch/x86/msi.c
>>> +++ b/xen/arch/x86/msi.c
>>> @@ -1411,6 +1411,70 @@ void __init early_msi_init(void)
>>>
flight 161022 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-libvirt
testid guest-start/debian.repeat
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware g
flight 161036 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail REGR. vs.
160646
test-armhf-armh
On Mon, 12 Apr 2021, Rahul Singh wrote:
> Hi Stefano,
>
> > On 10 Apr 2021, at 1:27 am, Stefano Stabellini
> > wrote:
> >
> > On Tue, 6 Apr 2021, Stefano Stabellini wrote:
> >> On Mon, 5 Apr 2021, Julien Grall wrote:
> >>> On 26/01/2021 22:58, Stefano Stabellini wrote:
> Hi all,
> >>>
> >>>
flight 161048 xen-4.14-testing real [real]
flight 161074 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161048/
http://logs.test-lab.xenproject.org/osstest/logs/161074/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
> From: Jan Beulich
> Sent: Thursday, April 1, 2021 4:43 PM
>
> This is effectively the other "half" of what was submitted as 4.15
> candidates in "[PATCH 0/4][4.15?] VT-d: mostly S3 related corrections".
>
> 1: improve save/restore of registers across S3
> 2: don't open-code dmar_readl()
> 3: b
> From: Jan Beulich
> Sent: Monday, April 12, 2021 7:34 PM
> Not having direct_mmio (used only once anyway) as a local variable gets
> the epte_get_entry_emt() invocation here in better sync with the other
> ones. While at it also reduce ipat's scope.
>
> Signed-off-by: Jan Beulich
Reviewed-by:
flight 161049 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161049/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 160774
test-amd64-amd64-xl-qemut-win7-a
flight 161054 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161054/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2072c22a0d63c780b0cc6377f6d4ffb116ad6144
baseline version:
ovmf 97336fdee4f9847e16463
Reviewed-by: Liming Gao
> -邮件原件-
> 发件人: de...@edk2.groups.io 代表 Anthony
> PERARD via groups.io
> 发送时间: 2021年4月12日 21:30
> 收件人: de...@edk2.groups.io
> 抄送: Laszlo Ersek ; Jordan Justen
> ; Ard Biesheuvel ;
> xen-devel@lists.xenproject.org; Anthony PERARD
> ; Julien Grall ; Michael D
> Kinn
In x86 kernel development the question came up whether we need to
support XENFEAT_gnttab_map_avail_bits not being set when running as a PV
guest.
This feature is active for PV guests since Xen 3.4.
So the basic question is: which is the oldest version of Xen we want to
support in the Linux kerne
1 - 100 of 101 matches
Mail list logo
