On 04/04/2023 7:46 am, Jan Beulich wrote:
> PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
> more than 32k pIRQ-s can be used by a domain. Document this upper bound.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> I was uncertain about also introducing a bo
Hi Anthony,
Thank you for your review
> On 30 Mar 2023, at 17:49, Anthony PERARD wrote:
>
> 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-capabi
On 04.04.2023 09:09, Andrew Cooper wrote:
> On 04/04/2023 7:46 am, Jan Beulich wrote:
>> PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
>> more than 32k pIRQ-s can be used by a domain. Document this upper bound.
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Andrew Cooper
On Tue, 2023-04-04 at 08:41 +0200, Jan Beulich wrote:
> On 03.04.2023 20:40, Oleksii wrote:
> > Hello Julien,
> > On Fri, 2023-03-31 at 22:05 +0100, Julien Grall wrote:
> > > Hi Oleksii,
> > >
> > > I was going to ack the patch but then I spotted something that
> > > would
> > > want some clarif
On 03.04.2023 18:28, Juergen Gross wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,8 +15,14 @@ config DEBUG_INFO
> bool "Compile Xen with debug info"
> default DEBUG
> help
> - If you say Y here the resulting Xen will include debugging info
> - resu
Stefan Hajnoczi wrote:
> All callers now pass is_external=false to aio_set_fd_handler() and
> aio_set_event_notifier(). The aio_disable_external() API that
> temporarily disables fd handlers that were registered is_external=true
> is therefore dead code.
>
> Remove aio_disable_external(), aio_enab
Besides a printk() the main effect is slight corruption of the start
info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
up as xen-3.0-x86_64p.
Note that no known users exist that would have developed a dependency on
the bogus magic string. In particular Linux, NetBSD, and mini-o
PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
more than 32k pIRQ-s can be used by a domain on x86. Document this upper
bound.
To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
parameter type) and setup_system_domains(). This is primarily to avoid
expos
* Juan Quintela (quint...@redhat.com) wrote:
> Stefan Hajnoczi wrote:
> > All callers now pass is_external=false to aio_set_fd_handler() and
> > aio_set_event_notifier(). The aio_disable_external() API that
> > temporarily disables fd handlers that were registered is_external=true
> > is therefore
On Mon, Apr 03, 2023 at 06:07:26PM +0200, Jan Beulich wrote:
> On 03.04.2023 17:38, Roger Pau Monné wrote:
> > On Mon, Apr 03, 2023 at 05:32:39PM +0200, Jan Beulich wrote:
> >> On 03.04.2023 12:14, Roger Pau Monne wrote:
> >>> Global p2m type recalculations (as triggered by logdirty) can create
> >
This is in order to be able to put MSR_ARCH_CAPS in a featureset. In
hindsight it was a mistake separating CPUID and read-only MSR data into
separate structs.
Patches 1-8 were posted previously and have had the feedback addressed.
Patches 9-15 are the result of splitting the older RFC patch 9 apa
We want to merge struct cpuid_policy and struct msr_policy together, and the
result wants to be called struct cpu_policy.
The current struct cpu_policy, being a pair of pointers, isn't terribly
useful. Rename the type to struct old_cpu_policy, but it will disappear
entirely once the merge is comp
These weren't great names to begin with, and using {leaves,msrs} matches up
better with the existing nr_{leaves,msr} parameters anyway.
Furthermore, by renaming these fields we can get away with using some #define
trickery to avoid the struct {cpuid,msr}_policy merge needing to happen in a
single
With all the complicated callers of x86_cpu_policies_are_compatible() updated
to use a single cpu_policy object, we can drop the final user of struct
old_cpu_policy.
Update x86_cpu_policies_are_compatible() to take (new) cpu_policy pointers,
reducing the amount of internal pointer chasing, and upd
These are already getting over-large for being inline functions, and are only
going to grow more over time. Out of line them, yielding the following net
delta from bloat-o-meter:
add/remove: 2/0 grow/shrink: 0/4 up/down: 276/-1877 (-1601)
Switch to the newer cpu_policy terminology while doing
Right now, they're the same underlying type, containing disjoint information.
Drop the d->arch.msr pointer, and union d->arch.cpuid to give it a second name
of cpu_policy in the interim.
Merge init_domain_{cpuid,msr}_policy() into a single init_domain_cpu_policy(),
moving the implementation into
Right now, they're the same underlying type, containing disjoint information.
Use a single object instead. Also take the opportunity to rename 'entries' to
'msrs' which is more descriptive, and more in line with nr_msrs being the
count of MSR entries in the API.
test-tsx uses xg_private.h to acc
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 is new
since the original logic was written.
As we're trying to phase out the
As with the cpuid side, use a temporary define to make struct msr_policy still
work.
Note, this means that domains now have two separate struct cpu_policy
allocations with disjoint information, and system policies are in a similar
position, as well as xc_cpu_policy objects in libxenguest. All of
Also merge lib/x86/cpuid.h entirely into lib/x86/cpu-policy.h
Use a temporary define to make struct cpuid_policy still work.
There's one forward declaration of struct cpuid_policy in
tools/tests/x86_emulator/x86-emulate.h that isn't covered by the define, and
it's easier to rename that now than t
On Mon, 2023-04-03 at 14:29 -0400, Stefan Hajnoczi wrote:
> There is no need to suspend activity between aio_disable_external() and
> aio_enable_external(), which is mainly used for the block layer's drain
> operation.
>
> This is part of ongoing work to remove the aio_disable_external() API.
>
>
Switch to the newer cpu_policy nomenclature. Do some easy cleanup of
includes.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
xen/arch/x86/cpu-policy.c | 752
xen/arch/x86/cpuid.c
As with struct domain, retain cpuid as a valid alias for local code clarity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* Retain cpuid compatibility alias.
* Split out of RFC patch.
---
tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 2 +-
tools/
Switch to the newer cpu_policy nomenclature.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
xen/arch/x86/cpu-policy.c | 84 +++
xen/arch/x86/include/asm/cpu-policy.h | 3 +
xen/arch/x8
With all code areas updated, drop the temporary defines and adjust all
remaining users.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* Split out of RFC patch
---
xen/arch/x86/cpu/mcheck/mce_intel.c| 2 +-
xen/arch/x86/cpuid.
With cpuid_policy and msr_policy merged to form cpu_policy, merge the
respective fuzzing logic.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
tools/fuzz/cpu-policy/afl-policy-fuzzer.c | 57 ---
1 file changed, 20 insertion
Adjust the API and comments appropriately.
x86_cpu_policy_fill_native() will eventually contain MSR reads, but leave a
TODO in the short term.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
tools/fuzz/cpu-policy/afl-poli
On Tue, Apr 04, 2023 at 11:19:08AM +0200, Jan Beulich wrote:
> Besides a printk() the main effect is slight corruption of the start
> info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
> up as xen-3.0-x86_64p.
>
> Note that no known users exist that would have developed a depend
On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
> applies to guests also when run on a 64-bit hypervisor: The "extended
> CR3" format has to be used there as well, to fit the address in the only
> 32-bit wide reg
flight 180131 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 180130 REGR. vs. 180116
Tests which are fai
On 04.04.2023 12:12, Roger Pau Monné wrote:
> On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
>> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
>> applies to guests also when run on a 64-bit hypervisor: The "extended
>> CR3" format has to be used there as well,
On 04/04/2023 10:20 am, Jan Beulich wrote:
> PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
> more than 32k pIRQ-s can be used by a domain on x86. Document this upper
> bound.
>
> To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
> parameter type) and se
On 04/04/2023 10:19 am, Jan Beulich wrote:
> Besides a printk() the main effect is slight corruption of the start
> info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
> up as xen-3.0-x86_64p.
>
> Note that no known users exist that would have developed a dependency on
> the bogus
On 30/03/2023 22:45, Julien Grall 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.
Hi Ayan,
Hi Julien,
I need some clarifications.
On 21/03/2023 14:03, Aya
On 04.04.2023 12:34, Andrew Cooper wrote:
> On 04/04/2023 10:20 am, Jan Beulich wrote:
>> --- a/xen/arch/arm/include/asm/irq.h
>> +++ b/xen/arch/arm/include/asm/irq.h
>> @@ -52,7 +52,7 @@ struct arch_irq_desc {
>>
>> extern const unsigned int nr_irqs;
>> #define nr_static_irqs NR_IRQS
>> -#defi
The stride values (based on 32-bit element size) were wrong for these
two test, yielding misleading output (especially when comparing with the
test variants also involving AVX512-VBMI2).
Also insert a missing blank on a nearby, related line.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emul
On 04/04/2023 11:48 am, Jan Beulich wrote:
> The stride values (based on 32-bit element size) were wrong for these
> two test, yielding misleading output (especially when comparing with the
> test variants also involving AVX512-VBMI2).
>
> Also insert a missing blank on a nearby, related line.
>
>
On Tue, Apr 04, 2023 at 12:31:31PM +0200, Jan Beulich wrote:
> On 04.04.2023 12:12, Roger Pau Monné wrote:
> > On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
> >> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
> >> applies to guests also when run on a 64-bit h
On Mon, Apr 03, 2023 at 10:47:11PM +0200, Philippe Mathieu-Daudé wrote:
> On 3/4/23 20:29, Stefan Hajnoczi wrote:
> > Only report a transport reset event to the guest after the SCSIDevice
> > has been unrealized by qdev_simple_device_unplug_cb().
> >
> > qdev_simple_device_unplug_cb() sets the SCS
On 15/02/2023 2:54 pm, Jan Beulich wrote:
> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
> applies to guests also when run on a 64-bit hypervisor:
Is this really true? Even when looking at Xen 4.2, 32bit guests are
required to pass a full 4k page, not a 32b quad.
Which
On 03/04/2023 2:26 pm, Roger Pau Monné wrote:
> On Mon, Apr 03, 2023 at 11:16:52AM +0100, Andrew Cooper wrote:
>> On 03/04/2023 9:57 am, Roger Pau Monné wrote:
>> (Quick tangent... Our PCI handling is currently very dumb.
>> pci_mmcfg_read() returns its value by pointer but the callers never
>> c
flight 180133 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180133/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180126
test-amd64-i386-xl-qemuu-win7-amd64
On 4/3/23 20:29, Stefan Hajnoczi wrote:
This patch is part of an effort to remove the aio_disable_external()
API because it does not fit in a multi-queue block layer world where
many AioContexts may be submitting requests to the same disk.
The SCSI emulation code is already in good shape to stop
On 4/3/23 20:29, Stefan Hajnoczi wrote:
The VuServer object has a refcount field and ref/unref APIs. The name is
confusing because it's actually an in-flight request counter instead of
a refcount.
Normally a refcount destroys the object upon reaching zero. The VuServer
counter is used to wake up
On 4/3/23 20:29, Stefan Hajnoczi wrote:
The aio_disable_external() API temporarily suspends file descriptor monitoring
in the event loop. The block layer uses this to prevent new I/O requests being
submitted from the guest and elsewhere between bdrv_drained_begin() and
bdrv_drained_end().
While
On 4/3/23 20:30, Stefan Hajnoczi wrote:
These functions must be called with the AioContext acquired:
/* Callers must hold exp->ctx lock */
void blk_exp_ref(BlockExport *exp)
...
/* Callers must hold exp->ctx lock */
void blk_exp_unref(BlockExport *exp)
Signed-off-by: Stefan Hajno
Hi Anthony,
Thanks for your review
> On 31 Mar 2023, at 15:23, Anthony PERARD wrote:
>
> On Mon, Mar 27, 2023 at 11:59:42AM +0100, Luca Fancellu wrote:
>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>> index 10f37990be57..adf48fe8ac1d 100644
>> --- a/docs/man/xl.cfg.5.pod
On 4/4/23 15:06, Stefan Hajnoczi wrote:
Would this be more useful as a qdev_is_realized() helper?
Yes. There are no other users, but I think a helper makes sense.
Agreed; anyway,
Reviewed-by: Paolo Bonzini
Paolo
On Fri, Mar 24, 2023 at 08:37:06PM +, Andrew Cooper wrote:
> On 24/03/2023 8:28 pm, Andrew Cooper wrote:
> > On 24/03/2023 6:58 pm, osstest service owner wrote:
> >> flight 179929 xen-unstable-smoke real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/179929/
> >>
> >> Regressions
On 04.04.2023 15:08, Andrew Cooper wrote:
> On 15/02/2023 2:54 pm, Jan Beulich wrote:
>> While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
>> applies to guests also when run on a 64-bit hypervisor:
>
> Is this really true? Even when looking at Xen 4.2, 32bit guests are
> req
On 04.04.2023 13:41, Roger Pau Monné wrote:
> On Tue, Apr 04, 2023 at 12:31:31PM +0200, Jan Beulich wrote:
>> On 04.04.2023 12:12, Roger Pau Monné wrote:
>>> On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
>>>
On Mon, Apr 03, 2023 at 02:29:52PM -0400, Stefan Hajnoczi wrote:
> Only report a transport reset event to the guest after the SCSIDevice
> has been unrealized by qdev_simple_device_unplug_cb().
>
> qdev_simple_device_unplug_cb() sets the SCSIDevice's qdev.realized field
> to false so that scsi_dev
This series adds support for a number of more or less recently announced
ISA extensions. Plus a little bit of (more or less related) cleanup. The
series interacts mildly (and only contextually) with the AVX512-FP16 one.
Note that patch 1 was previously posted standalone; the posting here is
unchang
Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its and FRED's bit at this occasion, thus allowing to
also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests, install write
This insn differs from WRMSR solely in the lack of serialization. Hence
the code used there can simply be used here as well, plus a feature
check of course. As there's no other infrastructure needed beyond
permitting the insn for PV privileged-op emulation (in particular no
separate new VMEXIT) we
For an unclear reason 0552a8cfda43 ("x86emul: track only rIP in emulator
state") converted the original struct cpu_user_regs instance to a
pointer, rather than dropping the field altogether: The pointer merely
aliases the one in the context structure.
Signed-off-by: Jan Beulich
--- a/xen/arch/x8
Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
now wants to construct and invoke a stub, make stub_exn available to it
via a new field in the emulator state structure.
Signed-off-by: Jan Beulich
---
# SDE: -grr or -srf
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/li
This can now also be used to reduce the number of parameters
x86emul_fpu() needs to take.
Signed-off-by: Jan Beulich
---
We could of course set the struct field once early in x86_emulate(), but
for now I think we're better off leaving it as NULL where not actually
needed.
--- a/xen/arch/x86/x86_
As in a few cases before (in particular: AVX512_IFMA), since the insns
here and in particular their memory access patterns follow the usual
scheme, I didn't think it was necessary to add a contrived test
specifically for them.
Signed-off-by: Jan Beulich
--- a/tools/libs/light/libxl_cpuid.c
+++ b
These are close relatives of the AVX-VNNI ISA extension. Since the insns
here and in particular their memory access patterns follow the usual
scheme (and especially the byte variants of AVX-VNNI), I didn't think it
was necessary to add a contrived test specifically for them.
While making the addit
Matching what was done earlier, explicit tests are added only for
irregular insn / memory access patterns.
Signed-off-by: Jan Beulich
---
SDE: -grr or -srf
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -242,6 +242,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by
On 04.04.2023 16:55, Jan Beulich wrote:
> These are "compound" instructions to issue a series of RDMSR / WRMSR
> respectively. In the emulator we can therefore implement them by using
> the existing msr_{read,write}() hooks. The memory accesses utilize that
> the HVM ->read() / ->write() hooks are
On 04.04.2023 11:52, Andrew Cooper wrote:
> These are already getting over-large for being inline functions, and are only
> going to grow more over time. Out of line them, yielding the following net
> delta from bloat-o-meter:
>
> add/remove: 2/0 grow/shrink: 0/4 up/down: 276/-1877 (-1601)
>
>
On 04.04.2023 11:52, Andrew Cooper wrote:
> Switch to the newer cpu_policy nomenclature.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On Tue, Apr 04, 2023 at 02:27:36PM +0100, Andrew Cooper wrote:
> On 03/04/2023 2:26 pm, Roger Pau Monné wrote:
> > On Mon, Apr 03, 2023 at 11:16:52AM +0100, Andrew Cooper wrote:
> >> On 03/04/2023 9:57 am, Roger Pau Monné wrote:
> >> (Quick tangent... Our PCI handling is currently very dumb.
> >>
On 04.04.2023 11:52, Andrew Cooper wrote:
> Switch to the newer cpu_policy nomenclature. Do some easy cleanup of
> includes.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
>
> v2:
> * New
> ---
> xen/arch/x86/cpu-polic
On 04.04.2023 17:04, Roger Pau Monné wrote:
> On Tue, Apr 04, 2023 at 02:27:36PM +0100, Andrew Cooper wrote:
>> On 03/04/2023 2:26 pm, Roger Pau Monné wrote:
>>> On Mon, Apr 03, 2023 at 11:16:52AM +0100, Andrew Cooper wrote:
On 03/04/2023 9:57 am, Roger Pau Monné wrote:
>> @@ -1104,6 +1092
On 04.04.2023 11:52, Andrew Cooper wrote:
> As with struct domain, retain cpuid as a valid alias for local code clarity.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 04.04.2023 11:52, Andrew Cooper wrote:
> With cpuid_policy and msr_policy merged to form cpu_policy, merge the
> respective fuzzing logic.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 04/04/2023 4:01 pm, Jan Beulich wrote:
> On 04.04.2023 11:52, Andrew Cooper wrote:
>> These are already getting over-large for being inline functions, and are only
>> going to grow more over time. Out of line them, yielding the following net
>> delta from bloat-o-meter:
>>
>> add/remove: 2/0
On 04.04.2023 11:52, Andrew Cooper wrote:
> Adjust the API and comments appropriately.
>
> x86_cpu_policy_fill_native() will eventually contain MSR reads, but leave a
> TODO in the short term.
That'll then require passing in a callback function anyway, such that
different environments can use dif
On 04/04/2023 4:34 pm, Jan Beulich wrote:
> On 04.04.2023 11:52, Andrew Cooper wrote:
>> Adjust the API and comments appropriately.
>>
>> x86_cpu_policy_fill_native() will eventually contain MSR reads, but leave a
>> TODO in the short term.
> That'll then require passing in a callback function anyw
On 04.04.2023 11:52, Andrew Cooper wrote:
> With all code areas updated, drop the temporary defines and adjust all
> remaining users.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 03.04.23 12:27, Juergen Gross wrote:
Hello Juergen
> bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
> can sleep.
>
> This requires to move the calls of create_active() out of the locked
> regions. This is no problem, as the worst which could happen would be
> a spuri
On 04/04/2023 4:16 pm, Jan Beulich wrote:
> On 04.04.2023 11:52, Andrew Cooper wrote:
>> Switch to the newer cpu_policy nomenclature. Do some easy cleanup of
>> includes.
>>
>> No practical change.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>> CC: Wei Li
On Tue, Apr 04, 2023 at 04:24:16PM +0200, Jan Beulich wrote:
> On 04.04.2023 13:41, Roger Pau Monné wrote:
> > On Tue, Apr 04, 2023 at 12:31:31PM +0200, Jan Beulich wrote:
> >> On 04.04.2023 12:12, Roger Pau Monné wrote:
> >>> On Wed, Feb 15, 2023 at 03:54:11PM +0100, Jan Beulich wrote:
> Whil
Currently it's impossible to get CPU's microcode revision from Xen after
late loading without looking into Xen logs which is not always convenient.
Add a new platform op in order to get the required data from Xen and
provide a wrapper for libxenctrl.
Signed-off-by: Sergey Dyasli
---
v3 --> v4:
-
flight 180137 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180137/
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
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
---
v3 --> v4:
- Replaced DECLARE_PLATFORM_OP
- Removed NULL checks
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/tools/inclu
Add an option to xen-ucode tool to print the currently loaded ucode
revision and also print it during usage info. Print CPU signature and
platform flags as well. The raw data comes from XENPF_get_cpu_version
and XENPF_get_ucode_revision platform ops.
Example output:
Intel:
CPU signature
On 31.03.2023 11:59, Roger Pau Monne wrote:
> Modify efi_find_gop_mode() so that passing cols or rows as 0 is
> interpreted as a request to attempt to keep the currently set mode,
> and do so if the mode query for information is successful and the depth
> is supported.
>
> Signed-off-by: Roger Pau
Posting v4 with addressed review comments. Changes from v3 are available
in each patch.
Sergey Dyasli (3):
tools/xenctrl: add xc_get_cpu_version()
x86/platform: introduce XENPF_get_ucode_revision
tools/xen-ucode: print information about currently loaded ucode
tools/include/xenctrl.h
On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> 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 th
On 04.04.2023 17:45, Andrew Cooper wrote:
> On 04/04/2023 4:16 pm, Jan Beulich wrote:
>> On 04.04.2023 11:52, Andrew Cooper wrote:
>>> @@ -20,10 +26,332 @@ struct cpu_policy __ro_after_init hvm_max_cpu_policy;
>>> struct cpu_policy __ro_after_init hvm_def_cpu_policy;
>>> #endif
>>>
>>> +const u
flight 180134 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180134/
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-amd64-libvirt 15 migrate-s
On 04/04/2023 2:51 pm, Anthony PERARD wrote:
> On Fri, Mar 24, 2023 at 08:37:06PM +, Andrew Cooper wrote:
>> On 24/03/2023 8:28 pm, Andrew Cooper wrote:
>>> On 24/03/2023 6:58 pm, osstest service owner wrote:
flight 179929 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject
Hi Julien,
On Wed, 2023-03-29 at 14:06 +0200, Jan Beulich wrote:
> > > > +void __init setup_initial_pagetables(void)
> > > > +{
> > > > + struct mmu_desc mmu_desc = { 0, 0, NULL, 0 };
> > > > +
> > > > + /*
> > > > + * Access to _{stard, end } is always PC-relative
> > > > + * thereb
On Wed, Mar 22, 2023 at 01:58:00PM +, Peter Hoyes wrote:
> From: Peter Hoyes
>
> Saving, restoring and migrating domains are not currently supported on
> arm and arm64 platforms, so xendomains prints the warning:
>
> An error occurred while saving domain:
> command not implemented
>
> w
On Tue, Apr 04, 2023 at 05:57:11PM +0200, Roger Pau Monné wrote:
> On Tue, Apr 04, 2023 at 04:24:16PM +0200, Jan Beulich wrote:
> > On 04.04.2023 13:41, Roger Pau Monné wrote:
> > > On Tue, Apr 04, 2023 at 12:31:31PM +0200, Jan Beulich wrote:
> > >> On 04.04.2023 12:12, Roger Pau Monné wrote:
> > >
On 30.03.23 10:35, Viresh Kumar wrote:
Hello Viresh
The strings won't be an exact match, and we are only looking to match
the prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Signed-off-by: Viresh Kumar
It feels to me
flight 180138 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180138/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fb89f62d2702faf7db7f7afef342467d4f0fba3c
baseline version:
ovmf 26997800c991f934b57eb
On Tue, 7 Mar 2023 at 18:27, David Woodhouse wrote:
>
> From: Paul Durrant
>
> Signed-off-by: Paul Durrant
> Signed-off-by: David Woodhouse
> Reviewed-by: Paul Durrant
> ---
Hi; Coverity points out a memory leak in this code (CID 1508098):
> +static struct qemu_xs_handle *libxenstore_open(vo
On Tue, 2023-04-04 at 18:35 +0100, Peter Maydell wrote:
> On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> wrote:
> >
> > From: Paul Durrant
> >
> > Signed-off-by: Paul Durrant
> > Signed-off-by: David Woodhouse
> > Reviewed-by: Paul Durrant
> > ---
>
> Hi; Coverity points out a memory leak i
On Tue, 4 Apr 2023 at 18:45, David Woodhouse wrote:
>
> On Tue, 2023-04-04 at 18:35 +0100, Peter Maydell wrote:
> > On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> > wrote:
> > >
> > > From: Paul Durrant
> > >
> > > Signed-off-by: Paul Durrant
> > > Signed-off-by: David Woodhouse
> > > Reviewed
On 30.03.23 11:43, Viresh Kumar wrote:
Hello Viresh
Currently, we add grant mapping related device tree properties if the
backend domain is not Dom0. While Dom0 is privileged and can do foreign
mapping for the entire guest memory, it is still okay for Dom0 to access
guest's memory via grant
On Tue, 2023-04-04 at 18:45 +0100, Peter Maydell wrote:
> On Tue, 4 Apr 2023 at 18:45, David Woodhouse
> wrote:
> >
> > On Tue, 2023-04-04 at 18:35 +0100, Peter Maydell wrote:
> > > On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> > >
> > > wrote:
> > > >
> > > > From: Paul Durrant
> > > >
> >
From: David Woodhouse
There was a superfluous allocation of the XS handle, leading to it
being leaked on both the error path and the success path (where it gets
allocated again).
Spotted by Coverity (CID 1508098).
Fixes: ba2a92db1ff6 ("hw/xen: Add xenstore operations to allow redirection to
in
On Tue, 4 Apr 2023 at 19:25, David Woodhouse wrote:
>
> From: David Woodhouse
>
> There was a superfluous allocation of the XS handle, leading to it
> being leaked on both the error path and the success path (where it gets
> allocated again).
>
> Spotted by Coverity (CID 1508098).
>
> Fixes: ba2a
flight 180140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 180137
Tests which
1 - 100 of 115 matches
Mail list logo
