On 30.03.2023 18:17, Roger Pau Monné wrote:
> On Thu, Mar 30, 2023 at 06:07:57PM +0200, Jan Beulich wrote:
>> On 30.03.2023 17:44, Roger Pau Monné wrote:
>>> I guess I'm slightly confused by the usage of both GOP and StdOut, I
>>> would assume if we have a gop, and can correctly initialize it there
flight 180073 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 180062
Tests which did no
flight 180069 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180069/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 17 guest-saverestorefail REGR. vs. 178042
test-amd64-amd64-pa
flight 180066 linux-5.4 real [real]
flight 180079 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180066/
http://logs.test-lab.xenproject.org/osstest/logs/180079/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386
flight 180074 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180074/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b08a19eae28e76fb5a296a604c27d06fab29b08a
baseline version:
ovmf e9e61671237e10f7d7672
flight 180076 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180076/
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
flight 180072 xen-unstable-smoke real [real]
flight 180075 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180072/
http://logs.test-lab.xenproject.org/osstest/logs/180075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Hi,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
/* Choose suitable "pa_range" according to the resulted "p2m_ipa_bits". */
for ( i = 0; i < ARRAY_SIZE(pa_range_info); i++ )
@@ -2324,14 +2323,13 @@ void __init setup_virt_paging(void)
if ( pa_range >= ARRAY_SIZE(pa_range_info)
Hi Ayan,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
The pabits, t0sz, root_order and sl0 values are the same as those for
ARM_64.
To me this read as the line should be common. But you still duplicate it.
In any case, you should justify this change with a pointer to the Arm
Arm. Not just s
Hi Ayan:
Title: Shouldn't you remove the _ or use uppercase?
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64. >
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v3 - 1. New patch introduced in v4
Hi,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
When 32 bit physical addresses are used (ie ARM_PA_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm 32-bit.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() m
Hi Ayan,
On 21/03/2023 14:03, 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
Hi Ayan,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
d
Hi Ayan,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
In future, we wish to support 32 bit physical address.
However, the current dt and fdt functions can only read u64 values.
Reading this again this is a bit misleading. At least the DT functions
are able to deal read 32-bit or 64-bit value
Hi,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
ARM_32. Thus, there i
flight 180062 xen-unstable real [real]
flight 180071 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180062/
http://logs.test-lab.xenproject.org/osstest/logs/180071/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 180070 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180070/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e9e61671237e10f7d7672ff74e8907941a954c1d
baseline version:
ovmf 6f0c65cdb073eb8ee8c1c
Hi all,
NOTE THE DATE CHANGE: The call has been pushed back by a week to avoid any
clashes with Easter holidays.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/HtfnjfjUlr9KcUC-vP2RGLXe/ and you can
edit to add items. Alternatively, you can reply to this mail directly.
Agenda it
Hi,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
1. One should use 'PRIpaddr' to display 'paddr_t' variables. However,
while creating nodes in fdt, the address (if present in the node name)
should be represented using 'PRIx64'. This is to be in conformance
with the following rule present in htt
Hi Jan,
On 30/03/2023 11:38, Jan Beulich wrote:
Signed-off-by: Jan Beulich
FWIW:
Acked-by: Julien Grall
Cheers,
--- a/Config.mk
+++ b/Config.mk
@@ -225,7 +225,7 @@ MINIOS_UPSTREAM_URL ?= https://xenbits.x
MINIOS_UPSTREAM_REVISION ?= 5bcb28aaeba1c2506a82fab0cdad0201cd9b54b3
SEABIO
flight 180061 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180061/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15 migrate-s
flight 180068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180068/
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
flight 180067 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180067/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6f0c65cdb073eb8ee8c1cb6fad5d0060ec86f3cc
baseline version:
ovmf 53eb26b238541799134aa
flight 180059 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
test-amd64-amd64-xl
On Mon, Mar 27, 2023 at 11:59:41AM +0100, Luca Fancellu wrote:
> ---
> tools/golang/xenlight/helpers.gen.go| 2 ++
> tools/golang/xenlight/types.gen.go | 1 +
> tools/include/arm-arch-capabilities.h | 33 +
Could you move that new file into "tools/include/xen-t
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Reviewed-by: P
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Acked-by: Dominik Brodowski
---
drivers/pcmcia/rsrc_nonstatic.c | 9 +++-
There might be a confusion with the implementation of the
pci_bus_for_each_resources() due to side effect of Logical
OR. Document entire macro and explain how it works and why
the conditional needs to be like that.
Signed-off-by: Andy Shevchenko
---
include/linux/pci.h | 20
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Reviewed-by: Philippe Mathieu-Daudé
---
drivers/eisa/pci_eisa.c | 4 ++--
1
From: Mika Westerberg
Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.
While at it drop doubled empty line before pdev_sort_resources().
No functional changes intended.
Sugge
kernel.h is being used as a dump for all kinds of stuff for a long time.
The COUNT_ARGS() and CONCATENATE() macros may be used in some places
without need of the full kernel.h dependency train with it.
Here is the attempt on cleaning it up by splitting out these macros().
Signed-off-by: Andy Shev
Introduce pci_resource_n() and replace open-coded implementations of it
in pci.h.
Signed-off-by: Andy Shevchenko
Reviewed-by: Philippe Mathieu-Daudé
---
include/linux/pci.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pc
Provide two new helper macros to iterate over PCI device resources and
convert users.
Looking at it, refactor existing pci_bus_for_each_resource() and convert
users accordingly.
Note, the amount of lines grew due to the documentation update.
Changelog v8:
- fixed issue with pci_bus_for_each_reso
On 30/03/2023 16:57, Ayan Kumar Halder wrote:
(Apologies, fixed the formatting issue)
Hi,
On 30/03/2023 16:50, Ayan Kumar Halder wrote:
Hi Xen experts,
I need some pointers on an issue I am facing.
I am running my downstream port of Xen on Cortex-R52 hardware. The
hardware consist of
On Thu, Mar 30, 2023 at 06:07:57PM +0200, Jan Beulich wrote:
> On 30.03.2023 17:44, Roger Pau Monné wrote:
> > On Mon, Dec 05, 2022 at 03:19:13PM +0100, Jan Beulich wrote:
> >> On 23.11.2022 16:45, Roger Pau Monne wrote:
> >>> Do not unconditionally set a mode in efi_console_set_mode(), do so
> >>>
On 30.03.2023 17:44, Roger Pau Monné wrote:
> On Mon, Dec 05, 2022 at 03:19:13PM +0100, Jan Beulich wrote:
>> On 23.11.2022 16:45, Roger Pau Monne wrote:
>>> Do not unconditionally set a mode in efi_console_set_mode(), do so
>>> only if the currently set mode is not valid.
>>
>> You don't say why y
(Apologies, fixed the formatting issue)
On 30/03/2023 16:50, Ayan Kumar Halder wrote:
Hi Xen experts,
I need some pointers on an issue I am facing.
I am running my downstream port of Xen on Cortex-R52 hardware. The
hardware consist of two R52 cores (the second core is in lockstep
mode). So,
Hi Xen experts,
I need some pointers on an issue I am facing.
I am running my downstream port of Xen on Cortex-R52 hardware. The
hardware consist of two R52 cores (the second core is in lockstep mode).
So, currently the hardware does not support SMP.
The issue is that Xen is unable to schedu
On Mon, Dec 05, 2022 at 03:19:13PM +0100, Jan Beulich wrote:
> On 23.11.2022 16:45, Roger Pau Monne wrote:
> > Do not unconditionally set a mode in efi_console_set_mode(), do so
> > only if the currently set mode is not valid.
>
> You don't say why you want to do so. Furthermore ...
>
> > --- a/x
On Thu, Mar 30, 2023 at 09:24:21PM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed various errors such like
> "i40e: probe of :3d:00.0 failed with error -12"
> due to commit (built with gcc-11):
>
> commit: d23d5938fd7ced817d6aa1ff86cd671ebbaebfc2 ("[PATCH v7 3/6] PCI:
On 30.03.2023 16:27, Roger Pau Monné wrote:
> On Thu, Mar 30, 2023 at 01:40:43PM +0200, Jan Beulich wrote:
>> On 30.03.2023 11:54, Roger Pau Monné wrote:
>>> On Thu, Mar 30, 2023 at 09:53:23AM +0200, Jan Beulich wrote:
On 29.03.2023 16:17, Roger Pau Monné wrote:
>>> Patch 8 I'm unsure, I guess
On Thu, Mar 30, 2023 at 01:59:37PM +0100, Andrew Cooper wrote:
> On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
> > On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
> >> tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->policy}()
> >> need
> >> to not operate on objects
On Thu, Mar 30, 2023 at 01:40:43PM +0200, Jan Beulich wrote:
> On 30.03.2023 11:54, Roger Pau Monné wrote:
> > On Thu, Mar 30, 2023 at 09:53:23AM +0200, Jan Beulich wrote:
> >> On 29.03.2023 16:17, Roger Pau Monné wrote:
> > Patch 8 I'm unsure, I guess it should be up to the user to decide
> > whet
flight 180065 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180065/
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
Hello everyone,
I've recently joined the Xen Project and I'm working at Vates on strategy and
innovation. I will also be formally representing the company at the Advisory
Board. First: I'm very excited to join and do what I can to help Xen, it's an
amazing project!
Second, and on to more concrete
On Wed, 2023-03-29 at 14:06 +0200, Jan Beulich wrote:
> On 29.03.2023 13:43, Oleksii wrote:
> > On Tue, 2023-03-28 at 17:34 +0200, Jan Beulich wrote:
> > > On 27.03.2023 19:17, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/mm.c
> > > > @@ -0,0 +1,277 @@
> > > > +#includ
On Wed, 2023-03-29 at 14:20 +0200, Jan Beulich wrote:
> On 29.03.2023 13:47, Oleksii wrote:
> > On Tue, 2023-03-28 at 16:44 +0100, Julien Grall wrote:
> > > On 28/03/2023 16:34, Jan Beulich wrote:
> > > > On 27.03.2023 19:17, Oleksii Kurochko wrote:
> > > > > --- a/xen/arch/riscv/include/asm/config
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni :
On Wed, 29 Mar 2023 10:02:59 +0200 you wrote:
> Issue the same error message in case an illegal page boundary crossing
> has been detected in both cases where this is tested.
>
> Suggested-by: Jan Beulich
> Signed-off-by: J
flight 180064 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180064/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 53eb26b238541799134aa5846530485c915735da
baseline version:
ovmf e3e88d90e8d777e38120c
On Sun, Mar 12, 2023 at 01:02:21PM +0100, Bernhard Beschow wrote:
> During the last patches, TYPE_PIIX3_XEN_DEVICE turned into a clone of
> TYPE_PIIX3_DEVICE. Remove this redundancy.
>
> Signed-off-by: Bernhard Beschow
> Reviewed-by: Michael S. Tsirkin
Reviewed-by: Anthony PERARD
Thanks,
--
On Sun, Mar 12, 2023 at 01:02:20PM +0100, Bernhard Beschow wrote:
> The previous patch unified handling of piix3_write_config() accross the
> PIIX3 device models which allows for assigning k->config_write once in the
> base class.
>
> Signed-off-by: Bernhard Beschow
> Reviewed-by: Michael S. Tsir
On Sun, Mar 12, 2023 at 01:02:19PM +0100, Bernhard Beschow wrote:
> Subscribe to pci_bus_fire_intx_routing_notifier() instead which allows for
> having a common piix3_write_config() for the PIIX3 device models.
>
> While at it, move the subscription into machine code to facilitate resolving
> TYPE
On Sun, Mar 12, 2023 at 01:02:18PM +0100, Bernhard Beschow wrote:
> xen_intx_set_irq() doesn't depend on PIIX3State. In order to resolve
> TYPE_PIIX3_XEN_DEVICE and in order to make Xen agnostic about the
> precise south bridge being used, set up Xen's PCI IRQ handling of PIIX3
> in the board.
>
>
On Sun, Mar 12, 2023 at 01:02:17PM +0100, Bernhard Beschow wrote:
> This is a preparational patch for the next one to make the following
> more obvious:
>
> First, pci_bus_irqs() is now called twice in case of Xen where the
> second call overrides the pci_set_irq_fn with the Xen variant.
pci_bus_
On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
> On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
>> tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->policy}()
>> need
>> to not operate on objects of differing lifetimes, so structs
>> {cpuid,msr}_policy need merging an
On 30.03.2023 14:31, Andrew Cooper wrote:
> On 30/03/2023 1:06 pm, Jan Beulich wrote:
>> On 30.03.2023 14:01, Andrew Cooper wrote:
>>> On 30/03/2023 11:16 am, Jan Beulich wrote:
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>
On Sun, Mar 12, 2023 at 01:02:16PM +0100, Bernhard Beschow wrote:
> xen_piix3_set_irq() isn't PIIX specific: PIIX is a single PCI device
> while xen_piix3_set_irq() maps multiple PCI devices to their respective
> IRQs, which is board-specific. Rename xen_piix3_set_irq() to communicate
> this.
>
>
On 30/03/2023 1:06 pm, Jan Beulich wrote:
> On 30.03.2023 14:01, Andrew Cooper wrote:
>> On 30/03/2023 11:16 am, Jan Beulich wrote:
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -893,7 +893,7 @@ int LLVMFuzzerTestOneInp
On 30/03/2023 12:24 pm, Jan Beulich wrote:
> These being local macros, the SHADOW prefix doesn't gain us much. What
> is more important to be aware of at use sites is that the supplied code
> is invoked for present entries only.
>
> While making the adjustment also properly use NULL for the 3rd arg
On 30/03/2023 11:18 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> Andrew Cooper (9):
>> x86: Rename struct cpu_policy to struct old_cpuid_policy
>> x86: Rename {domctl,sysctl}.cpu_policy.{cpuid,msr_policy} fields
> Nit: I guess the last closing brace wants moving forward
On 30.03.2023 14:01, Andrew Cooper wrote:
> On 30/03/2023 11:16 am, Jan Beulich wrote:
>> On 29.03.2023 22:51, Andrew Cooper wrote:
>>> Looking at this diff, I'm wondering whether keeping
>>>
>>> union {
>>> struct cpu_policy *cpuid;
>>> struct cpu_policy *cpu_policy;
>>> };
On 30/03/2023 11:16 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> Looking at this diff, I'm wondering whether keeping
>>
>> union {
>> struct cpu_policy *cpuid;
>> struct cpu_policy *cpu_policy;
>> };
>>
>> permentantly might be a good idea, because d
Hello,
On Wed, 2023-03-29 at 10:02 +0200, Juergen Gross wrote:
> Issue the same error message in case an illegal page boundary crossing
> has been detected in both cases where this is tested.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Juergen Gross
As this was intended to be part of:
xen/
On 30/03/2023 11:08 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> --- a/tools/libs/guest/xg_cpuid_x86.c
>> +++ b/tools/libs/guest/xg_cpuid_x86.c
>> @@ -868,9 +868,7 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch,
>> xc_cpu_policy_t *host,
>>
On 30/03/2023 11:04 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> /* Sanity test various invariants we expect in the default/max policies. */
>> static void test_guest_policies(const struct xc_cpu_policy *max,
>> const struct xc_cpu_policy
On 30.03.2023 11:54, Roger Pau Monné wrote:
> On Thu, Mar 30, 2023 at 09:53:23AM +0200, Jan Beulich wrote:
>> On 29.03.2023 16:17, Roger Pau Monné wrote:
>>> Do we expect to be able to split other opcode handling into separate
>>> files?
>>
>> As per above, "expect" is perhaps too optimistic. I'd s
While 670d6b908ff2 ('x86 shadow: Move the shadow linear mapping for
n-on-3-on-4 shadows so') bumped the amount by one too little for the
32-on-64 case (which luckily was dead code, and hence a bump wasn't
necessary in the first place), 0b841314dace ('x86/shadow:
sh_{make,destroy}_monitor_table() ar
It looks like in the combination of aff8bf94ce65 ('x86/shadow: only
4-level guest code needs building when !HVM') and 0b841314dace
('x86/shadow: sh_{make,destroy}_monitor_table() are "even more" HVM-
only') I didn't go quite far enough: SH_type_monitor_table is also
effectively unused when !HVM.
T
With an initial mode installed by shadow_vcpu_init(), there's no need
for sh_update_paging_modes() to deal with the "mode is still unset"
case. Leave an assertion, though.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/co
While benign at present, it is still a little fragile to operate on a
wrong "old_mode" value in sh_update_paging_modes(). This can happen when
no monitor table was present initially - we'd create one for the new
mode without updating old_mode. Correct this in two ways, each of which
would be suffic
Emulation related functions are involved in HVM handling only, and in
some cases they even invoke such checks after having already done things
which are valid for HVM domains only. OOS active also implies HVM. In
sh_remove_all_mappings() one of the two checks is redundant with an
earlier paging_mod
The function is used from (HVM-only) OOS code only - replace the
respective #ifdef inside the function to make this more obvious. (Note
that SHOPT_OUT_OF_SYNC won't be set when !HVM, so the #ifdef surrounding
the function is already sufficient.)
Requested-by: Andrew Cooper
Signed-off-by: Jan Beul
The code has been identified as HVM-only, and its main functions are
pretty well isolated. Move them to their own file. While moving, besides
making two functions non-static, do a few style adjustments, mainly
comment formatting, but leave the code otherwise untouched.
Signed-off-by: Jan Beulich
shadow_mode_...(), with the exception of shadow_mode_enabled(), are
shorthands for shadow_mode_enabled() && paging_mode_...(). While
potentially useful outside of shadow-internal functions, when we already
know that we're dealing with a domain in shadow mode, the "paging"
checks are sufficient and
When in 3-level guest mode we help a guest to stay alive, we also
shouldn't emit a trace entry to the contrary. Move the invocation up
into the respective #ifdef, noting that while this moves it into the
locked region, emitting trace records with the paging lock held is okay
(as done elsewhere as w
There's no need for an indirect call here, as the mode is invariant
throughout the entire paging-locked region. All it takes to avoid it is
to have a forward declaration of sh_update_cr3() in place.
Signed-off-by: Jan Beulich
---
I find this and the respective Win7 related comment suspicious: If
validate_guest_pt_write(), by calling sh_validate_guest_entry(), already
guarantees the needed update of log-dirty information. Move the
operation into the sole code path needing it (when SHOPT_SKIP_VERIFY is
enabled), making clear that only one such call is needed.
Signed-off-by: Jan Beulich
--
FOREACH_PRESENT_LE(), as their names (now) say, already invoke the
"body" only when the present bit is set; no need to re-do the check.
While there also
- stop open-coding mfn_to_maddr() in code being touched (re-indented)
anyway,
- stop open-coding mfn_eq() in code being touched or in adjacent
These being local macros, the SHADOW prefix doesn't gain us much. What
is more important to be aware of at use sites is that the supplied code
is invoked for present entries only.
While making the adjustment also properly use NULL for the 3rd argument
at respective invocation sites.
Requested-by:
This is kind of fallout from XSA-427 investigations, partly related to
there having been a more intrusive first approach.
Most patches aren't really dependent upon one another, so can probably
go in independently (as they get acked).
A few patches from v1 went in, but there are also three new pat
On 30/03/2023 10:40 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> Right now, they're the same underlying type, containing disjoint information.
>>
>> Introduce a new cpu-policy.{h,c} to be the new location for all policy
>> handling logic. Place the combined objects in __ro
On 30.03.2023 13:11, Andrew Cooper wrote:
> On 30/03/2023 10:30 am, Jan Beulich wrote:
>> On 29.03.2023 22:51, Andrew Cooper wrote:
>>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>>> @@ -3,7 +3,6 @@
>>> #define XEN_LIB_X86_POLICIES_H
>>>
>>> #inclu
On 30/03/2023 11:00 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> @@ -573,7 +574,6 @@ int arch_vcpu_create(struct vcpu *v)
>> /* Idle domain */
>> v->arch.cr3 = __pa(idle_pg_table);
>> rc = 0;
>> -v->arch.msrs = ZERO_BLOCK_PTR; /* Catch str
On 30/03/2023 10:30 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>> @@ -3,7 +3,6 @@
>> #define XEN_LIB_X86_POLICIES_H
>>
>> #include
>> -#include
>>
>> #define FEATURESET_1d
In an entirely different context I came across Linux commit 428e3d08574b
("KVM: x86: Fix zero iterations REP-string"), which points out that
we're still doing things wrong: For one, there's no zero-extension at
all on AMD. And then while RCX is zero-extended from 32 bits uniformly
for all string in
On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
> tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->policy}() need
> to not operate on objects of differing lifetimes, so structs
> {cpuid,msr}_policy need merging and cpu_policy is the obvious name.
So the problem is tha
On 30.03.2023 12:41, Luca Fancellu wrote:
>
>
>> On 28 Mar 2023, at 11:14, Jan Beulich wrote:
>>
>> On 27.03.2023 12:59, Luca Fancellu wrote:
>>> --- a/xen/arch/arm/arm64/sve.c
>>> +++ b/xen/arch/arm/arm64/sve.c
>>> @@ -124,3 +124,15 @@ int __init sve_parse_dom0_param(const char *str_begin,
>>>
> On 28 Mar 2023, at 11:14, Jan Beulich wrote:
>
> On 27.03.2023 12:59, Luca Fancellu wrote:
>> --- a/xen/arch/arm/arm64/sve.c
>> +++ b/xen/arch/arm/arm64/sve.c
>> @@ -124,3 +124,15 @@ int __init sve_parse_dom0_param(const char *str_begin,
>> const char *str_end)
>> {
>> return parse_integ
... in order to also intercept Dom0 accesses through the alias ports.
Also stop intercepting accesses to the CMOS ports if we won't ourselves
use the CMOS RTC, because of there being none.
Note that rtc_init() deliberately uses 16 as the upper loop bound,
despite probe_cmos_alias() using 8: The h
Signed-off-by: Jan Beulich
--- a/Config.mk
+++ b/Config.mk
@@ -225,7 +225,7 @@ MINIOS_UPSTREAM_URL ?= https://xenbits.x
MINIOS_UPSTREAM_REVISION ?= 5bcb28aaeba1c2506a82fab0cdad0201cd9b54b3
SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git
-SEABIOS_UPSTREAM_REVISION ?= rel-1
flight 180057 qemu-mainline real [real]
flight 180063 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180057/
http://logs.test-lab.xenproject.org/osstest/logs/180063/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 29.03.2023 22:51, Andrew Cooper wrote:
> tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->policy}() need
> to not operate on objects of differing lifetimes, so structs
> {cpuid,msr}_policy need merging and cpu_policy is the obvious name.
>
> But this does mean that we now have
>
On 29.03.2023 22:51, Andrew Cooper wrote:
> Looking at this diff, I'm wondering whether keeping
>
> union {
> struct cpu_policy *cpuid;
> struct cpu_policy *cpu_policy;
> };
>
> permentantly might be a good idea, because d->arch.cpuid->$X reads rather
> better than d->arch
On 29.03.2023 22:51, Andrew Cooper wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -868,9 +868,7 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch,
> xc_cpu_policy_t *host,
> xc_cpu_policy_t *guest)
> {
> struc
On 29.03.2023 22:51, Andrew Cooper wrote:
> /* Sanity test various invariants we expect in the default/max policies. */
> static void test_guest_policies(const struct xc_cpu_policy *max,
> const struct xc_cpu_policy *def)
> {
> -const struct cpuid_policy *cm
On 29.03.2023 22:51, Andrew Cooper wrote:
> @@ -573,7 +574,6 @@ int arch_vcpu_create(struct vcpu *v)
> /* Idle domain */
> v->arch.cr3 = __pa(idle_pg_table);
> rc = 0;
> -v->arch.msrs = ZERO_BLOCK_PTR; /* Catch stray misuses */
> }
Is this intentional? It's
On Thu, Mar 30, 2023 at 09:53:23AM +0200, Jan Beulich wrote:
> On 29.03.2023 16:17, Roger Pau Monné wrote:
> > On Tue, Mar 28, 2023 at 04:48:10PM +0200, Jan Beulich wrote:
> >> On 28.03.2023 16:19, Roger Pau Monné wrote:
> >>> On Wed, Jun 15, 2022 at 11:57:54AM +0200, Jan Beulich wrote:
> ...
On 29.03.2023 22:51, Andrew Cooper wrote:
> Right now, they're the same underlying type, containing disjoint information.
>
> Introduce a new cpu-policy.{h,c} to be the new location for all policy
> handling logic. Place the combined objects in __ro_after_init, which has
> appeared since the orig
On 29.03.2023 22:51, Andrew Cooper wrote:
> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -3,7 +3,6 @@
> #define XEN_LIB_X86_POLICIES_H
>
> #include
> -#include
>
> #define FEATURESET_1d 0 /* 0x0001.edx */
> #define FEATURESET_1c
Remove the hlist devines/functions and the rcu related functions from
tools/xenstore/list.h, as they are not used.
Signed-off-by: Juergen Gross
---
tools/xenstore/list.h | 227 --
1 file changed, 227 deletions(-)
diff --git a/tools/xenstore/list.h b/tools
1 - 100 of 132 matches
Mail list logo
