flight 180139 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180139/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180133
test-amd64-i386-xl-qemuu-win7-amd64
On Sat, Mar 25, 2023 at 8:25 AM Andrew Cooper wrote:
>
> * Correct comments in arm{32,64}/head.S
> * Provide Linker assertions to check the safety of the zeroing loops
>
> Signed-off-by: Andrew Cooper
Acked-by: Alistair Francis
Alistair
> ---
> CC: Stefano Stabellini
> CC: Julien Grall
>
flight 180136 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180136/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180088
test-amd64-amd64-xl-qemuu-ws16-amd6
The strings won't be an exact match, as 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.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device")
Signed-off-by: Viresh Kumar
---
V1->V2:
For generic virtio devices, where we don't need to add compatible or
other special DT properties, the type field is set to "virtio,device".
But this misses the case where the user sets the type with a valid
virtio device id as well, like "virtio,device26" for file system device.
Update documentat
flight 180135 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180135/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvshim 22 guest-start/debian.repeat fail in 180131 pass in
180135
test-amd64-amd64-freebsd1
On 04-04-23, 21:16, Oleksandr Tyshchenko wrote:
> ok, probably makes sense
While testing both foreign and grant mappings I stumbled upon another
related problem. How do I control the creation of iommu node from
guest configuration file, irrespective of the domain backend is
running at ? This is wh
On 04/04/2023 3:49 pm, Jan Beulich wrote:
> 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 affec
flight 180143 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180143/
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 180141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180141/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7df447930c42addaf2cc0d32916141d95ded677e
baseline version:
ovmf fb89f62d2702faf7db7f7
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
v3:
* Update x86_cpu_policy_lookup
On Tue, Apr 04, 2023 at 03:43:20PM +0200, Paolo Bonzini wrote:
> 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
On Tue, Apr 04, 2023 at 03:46:34PM +0200, Paolo Bonzini wrote:
> 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 hol
On 04/04/2023 5:14 pm, Jan Beulich wrote:
> 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 hv
On 04/04/2023 3:21 pm, Jan Beulich wrote:
> 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 wh
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
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
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, 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
> > > >
> >
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, 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 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, 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
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 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
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 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
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 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
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 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
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
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 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
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
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
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
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:
-
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
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 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 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 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:
> 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: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:
> 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 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 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:
> 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 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.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
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 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
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
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 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
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
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_
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
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
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
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 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
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
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 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 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 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
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/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
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: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:
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
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 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
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 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 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 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.
>
>
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 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
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 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 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 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,
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 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
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
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
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
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.
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
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. 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
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.
>
>
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
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
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
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
1 - 100 of 115 matches
Mail list logo
