>>> On 24.04.19 at 12:47, wrote:
> On 24/04/2019 01:20, Stefano Stabellini wrote:
>> On Mon, 22 Apr 2019, Julien Grall wrote:
>>> This code is pretty nasty, but I haven't found a better way for avoiding
>>> to check if CONFIG_DEBUG is enabled when the target clean is called.
>>>
>>> Ideally we wil
>>> On 22.05.19 at 17:50, wrote:
> x86_cpuid_copy_to_buffer() currently serialises the full content of the
> various subleaf unions. While leaves 4, 0xb and 0xd don't have a concrete
> max_subleaf field, they do have well defined upper bounds.
>
> Diffing the results of `xen-cpuid -p` shows the
>>> On 22.05.19 at 18:42, wrote:
> On Mon, May 20, 2019 at 09:26:37AM -0600, Jan Beulich wrote:
>> >>> On 20.05.19 at 16:04, wrote:
>> > On Fri, May 17, 2019 at 04:52:32AM -0600, Jan Beulich wrote:
>> >> @@ -452,15 +452,18 @@ static vmask_t *irq_get_used_vector_mask
>> >> int vector;
flight 136640 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
Hi,
On 23/05/2019 00:26, Stefano Stabellini wrote:
From: Stefano Stabellini
On arm64 swiotlb is already initialized by mem_init. We don't want to
Arm64 will not always initialize the swiotlb. It will only be done if the user
force it or there are memory above the DMA limit.
initialize it
>>> On 22.05.19 at 20:10, wrote:
> DSDT for qemu-xen lacks _STA method of PCI slot object. If _STA method
> doesn't exist then the slot is assumed to be always present and active
> which in conjunction with _EJ0 method makes every device ejectable for
> an OS even if it's not the case.
>
> qemu-k
Hi Jan,
Thank you for the feedback.
On 5/23/19 9:27 AM, Jan Beulich wrote:
On 24.04.19 at 12:47, wrote:
On 24/04/2019 01:20, Stefano Stabellini wrote:
On Mon, 22 Apr 2019, Julien Grall wrote:
This code is pretty nasty, but I haven't found a better way for avoiding
to check if CONFIG_DEBUG i
On Wed, May 22, 2019 at 07:54:42PM +0200, Olaf Hering wrote:
> Am Wed, 22 May 2019 15:51:40 +0100
> schrieb Anthony PERARD :
>
> > Can you give it a try with one of the affected qemu? (qemu-xen-4.10 or
> > qemu-xen-4.11)
>
> Thanks for the patch. Unfortunately there is no easy way to trigger the
>>> On 22.05.19 at 18:45, wrote:
> alternative_callN using inline assembly to generate the alternative
> patch sites should be using the ALTERNATIVE C preprocessor macro
> rather than the ALTERNATIVE assembly macro,
Why? See INDIRECT_{CALL,JMP}. My goal, as said on irc, would be
to eventually eli
Roger Pau Monne writes ("[Xen-devel] [PATCH 1/6] osstest: introduce a helper to
stash a whole directory"):
> Without compressing it.
You've open-coded a recursive directory copy. Is rsync available on
$ho at this point ? I think maybe it could be ...
Ian.
_
Roger Pau Monne writes ("[Xen-devel] [PATCH 2/6] osstest: introduce a helper to
create a weblink to a directory"):
> +sub create_weblink ($$$) {
> +my ($ho, $tail, $target) = @_;
> +my $wf_rhs= hostnamepath($ho)."_".$tail;
> +my $wf_common= $c{WebspaceCommon}.$wf_rhs;
> +my $wf_url
Roger Pau Monne writes ("[Xen-devel] [PATCH 3/6] osstest: allow to perform
multiple anoints in the same transaction"):
> Note that most of the changes in this patch is code movement in order
> to place the database accessors inside of a loop that iterates over
> the input parameters.
Sorry to be
Roger Pau Monne writes ("[Xen-devel] [PATCH 4/6] osstest: introduce a helper to
get the svn revision of a git commit"):
> This only works when the svn revision is stored as a git note
> with the format 'revision='.
Wow. This is pretty ugly.
> Such conversion is required in order to bootstrap a
Roger Pau Monne writes ("[Xen-devel] [PATCH 5/6] osstest: introduce a script to
build a FreeBSD package repository"):
> The building of the binary packages itself is done with the poudriere
> tool, that given a set of port names generates a binary package
> repository with the requested packages a
This also introduced the top-level Guest Documentation section.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
The rendered version can be viewed at:
https://
The various pieces of the hypercall page infrastructure have grown
organically over time and ended up in a bit of a mess.
* Rename all functions to be of the form *_init_hypercall_page(). This
makes them somewhat shorter, and means they can actually be grepped
for in one go.
* Move init_h
For the rendered result (along with some other in-progress documentation),
see:
https://andrewcoop-xen.readthedocs.io/en/docs-devel/guest-guide/hypercall-abi.html
Andrew Cooper (2):
x86: init_hypercall_page() cleanup
docs: Introduce some hypercall page documentation
docs/guest-guide/hyperca
On Thu, May 23, 2019 at 11:20:15AM +0100, Andrew Cooper wrote:
> The various pieces of the hypercall page infrastructure have grown
> organically over time and ended up in a bit of a mess.
>
> * Rename all functions to be of the form *_init_hypercall_page(). This
>makes them somewhat shorter
On Thu, May 23, 2019 at 11:20:16AM +0100, Andrew Cooper wrote:
> This also introduced the top-level Guest Documentation section.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://list
This avoids opencoding the slightly-awkward logic. More uses of these
wrappers will be introduced shortly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
I've decided to introduce this patch ahead of "[PATCH] libx86: Elide more
empty CPUID leaves when serial
On 23/05/2019 09:33, Jan Beulich wrote:
On 22.05.19 at 17:50, wrote:
>> x86_cpuid_copy_to_buffer() currently serialises the full content of the
>> various subleaf unions. While leaves 4, 0xb and 0xd don't have a concrete
>> max_subleaf field, they do have well defined upper bounds.
>>
>> Dif
Roger Pau Monne writes ("[Xen-devel] [PATCH 5/6] osstest: introduce a script to
build a FreeBSD package repository"):
> diff --git a/make-freebsd-flight b/make-freebsd-flight
> index d3c413b5..fc3d2d83 100755
> --- a/make-freebsd-flight
> +++ b/make-freebsd-flight
> @@ -38,13 +38,15 @@ job_create_
>>> On 23.05.19 at 12:23, wrote:
> On Thu, May 23, 2019 at 11:20:15AM +0100, Andrew Cooper wrote:
>> The various pieces of the hypercall page infrastructure have grown
>> organically over time and ended up in a bit of a mess.
>>
>> * Rename all functions to be of the form *_init_hypercall_page()
>>> On 23.05.19 at 12:20, wrote:
> This also introduced the top-level Guest Documentation section.
>
> Signed-off-by: Andrew Cooper
Large parts of this are entirely x86-centric, yet hypercalls exist
for Arm as well. If this is intentional, then I think you should say
so above.
Jan
_
On 23/05/2019 11:56, Jan Beulich wrote:
On 23.05.19 at 12:20, wrote:
>> This also introduced the top-level Guest Documentation section.
>>
>> Signed-off-by: Andrew Cooper
> Large parts of this are entirely x86-centric, yet hypercalls exist
> for Arm as well. If this is intentional, then I th
Roger Pau Monne writes ("[Xen-devel] [PATCH 6/6] osstest: use a locally built
pkg repository for FreeBSD"):
> This removes the dependency on the official pkg repository, which is
> dangerous when not testing stable branches, since the ABI of the
> development branch is not stable, and thus it's ea
>>> On 23.05.19 at 13:01, wrote:
> On 23/05/2019 11:56, Jan Beulich wrote:
> On 23.05.19 at 12:20, wrote:
>>> This also introduced the top-level Guest Documentation section.
>>>
>>> Signed-off-by: Andrew Cooper
>> Large parts of this are entirely x86-centric, yet hypercalls exist
>> for Arm
>>> On 23.05.19 at 12:27, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -660,9 +660,7 @@ static bool valid_xcr0(u64 xcr0)
> int validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t
> xcr0_accum,
> const struct xsave_hdr *hdr)
> {
> -
On 23/05/2019 12:52, Jan Beulich wrote:
On 23.05.19 at 12:27, wrote:
>> --- a/xen/arch/x86/xstate.c
>> +++ b/xen/arch/x86/xstate.c
>> @@ -660,9 +660,7 @@ static bool valid_xcr0(u64 xcr0)
>> int validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t
>> xcr0_accum,
>>
On 23/05/2019 12:41, Jan Beulich wrote:
On 23.05.19 at 13:01, wrote:
>> On 23/05/2019 11:56, Jan Beulich wrote:
>> On 23.05.19 at 12:20, wrote:
This also introduced the top-level Guest Documentation section.
Signed-off-by: Andrew Cooper
>>> Large parts of this are entirel
The first patch is something I had meant to do forever since the introduction
of mwait-idle. The 2nd patch addresses a latent problem (becoming an active
one with patch 3) in C-state selection when actually entering an idle state.
The 3rd patch is my counterproposal to Brian's intended abuse (as I
>>> On 23.05.19 at 13:59, wrote:
> On 23/05/2019 12:52, Jan Beulich wrote:
> On 23.05.19 at 12:27, wrote:
>>> --- a/xen/include/xen/lib/x86/cpuid.h
>>> +++ b/xen/include/xen/lib/x86/cpuid.h
>>> @@ -308,6 +308,18 @@ static inline void cpuid_featureset_to_policy(
>>> p->feat._7a1 = fs[FEA
>>> On 23.05.19 at 14:02, wrote:
> On 23/05/2019 12:41, Jan Beulich wrote:
> On 23.05.19 at 13:01, wrote:
>>> On 23/05/2019 11:56, Jan Beulich wrote:
>>> On 23.05.19 at 12:20, wrote:
> This also introduced the top-level Guest Documentation section.
>
> Signed-off-by: Andrew C
While the MWAIT idle driver already takes it to mean an actual C state,
the ACPI idle driver so far used it as a list index. The list index,
however, is an implementation detail of Xen and affected by firmware
settings (i.e. not necessarily uniform for a particular system).
While touching this cod
For one on recent AMD CPUs entering C1 (if available at all) requires
use of MWAIT, while HLT (i.e. default_idle()) would put the processor
into as deep as CC6. And then even on other vendors' CPUs we should
avoid entering default_idle() when the intended state can be reached
by using the active id
At least for more recent CPUs, following what BKDG / PPR suggest for the
BIOS to surface via ACPI we can make ourselves independent of Dom0
uploading respective data.
Signed-off-by: Jan Beulich
---
TBD: Can we set local_apic_timer_c2_ok to true? I can't seem to find any
statement in the BKDG
From: Ross Lagerwall
Allow limiting the max C-state sub-state by appending to the max_cstate
command-line parameter. E.g. max_cstate=1,0
The limit only applies to the highest legal C-state. For example:
max_cstate = 1, max_csubstate = 0 ==> C0, C1 okay, but not C1E
max_cstate = 1, max_csubstate
From: Ross Lagerwall
Signed-off-by: Ross Lagerwall
Make handling in do_pm_op() more homogeneous: Before interpreting
op->cpuid as such, handle all operations not acting on a particular
CPU. Also expose the setting via xenpm.
Signed-off-by: Jan Beulich
--- a/tools/libxc/xc_pm.c
+++ b/tools/li
>>> On 20.05.19 at 12:18, wrote:
> One path in dom0_construct_pv() returns -1 unlike all other error paths.
> Switch it to returning -EINVAL.
>
> This was last modified by c/s c84481fb XSA-55, but the bug predates that
> series. However, this patch did (for no obvious reason) introduce a
> bifur
>>> On 20.05.19 at 12:18, wrote:
> For consistency with other command line options.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenprojec
>>> On 20.05.19 at 12:18, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -675,12 +675,16 @@ Controls for how dom0 is constructed on x86 systems.
> selected mode.
> * For a PVH dom0, the hardware must have VT-x/SVM extensions
> avail
flight 136692 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 135813
test-amd64-amd64-qemuu-nested-am
>>> On 20.05.19 at 12:18, wrote:
> We currently have an asymmetric setup where CONFIG_VERBOSE_DEBUG controls
> extra diagnostics for a PV dom0, and opt_dom0_verbose controls extra
> diagnostics for a PVH dom0.
>
> Default opt_dom0_verbose to CONFIG_VERBOSE_DEBUG and use opt_dom0_verbose
> consist
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qcow2
testid debian-di-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbi
There are a number of pointless __packed attributes which cause gcc 9 to
legitimately warn:
utils.c: In function 'vtd_dump_iommu_info':
utils.c:287:33: error: converting a packed 'struct IO_APIC_route_entry' pointer
(alignment 1) to a 'struct IO_APIC_route_remap_entry' pointer (alignment 8) may
>>> On 21.05.19 at 09:45, wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used for memory loads in helper functions
> and macros. To avoid speculative out-of-bound accesses, we use the
> array_index_nospec macro where applicable, or the bl
>>> On 21.05.19 at 09:45, wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. To avoid speculative out-of-bound accesses, we
> use the array_index_nospec macro where applicabl
On Thu, May 23, 2019 at 07:54:10AM -0600, Jan Beulich wrote:
> There are a number of pointless __packed attributes which cause gcc 9 to
> legitimately warn:
>
> utils.c: In function 'vtd_dump_iommu_info':
> utils.c:287:33: error: converting a packed 'struct IO_APIC_route_entry'
> pointer (alignme
On 23/05/2019 15:20, Wei Liu wrote:
> On Thu, May 23, 2019 at 07:54:10AM -0600, Jan Beulich wrote:
>> There are a number of pointless __packed attributes which cause gcc 9 to
>> legitimately warn:
>>
>> utils.c: In function 'vtd_dump_iommu_info':
>> utils.c:287:33: error: converting a packed 'struc
On Thu, May 23, 2019 at 03:35:01PM +0100, Andrew Cooper wrote:
> On 23/05/2019 15:20, Wei Liu wrote:
> > On Thu, May 23, 2019 at 07:54:10AM -0600, Jan Beulich wrote:
> >> There are a number of pointless __packed attributes which cause gcc 9 to
> >> legitimately warn:
> >>
> >> utils.c: In function
>>> On 21.05.19 at 09:45, wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. Depending on the grant table version, the
> size of elements in containers differ. As the base da
On Thu, May 23, 2019 at 02:57:49AM -0600, Jan Beulich wrote:
> >>> On 22.05.19 at 20:10, wrote:
> > DSDT for qemu-xen lacks _STA method of PCI slot object. If _STA method
> > doesn't exist then the slot is assumed to be always present and active
> > which in conjunction with _EJ0 method makes ever
>>> On 23.05.19 at 17:20, wrote:
> On Thu, May 23, 2019 at 02:57:49AM -0600, Jan Beulich wrote:
>> >>> On 22.05.19 at 20:10, wrote:
>> > DSDT for qemu-xen lacks _STA method of PCI slot object. If _STA method
>> > doesn't exist then the slot is assumed to be always present and active
>> > which in
>>> On 10.05.19 at 18:10, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -688,8 +688,8 @@ static int vpci_msi_update(const struct pci_dev *pdev,
> uint32_t data,
> {
> gdprintk(XENLOG_ERR,
> "%04x:%02x:%02x.%u: failed to bin
flight 136703 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 136503
Tests which did not
On 21/05/2019 16:46, Jan Beulich wrote:
On 21.05.19 at 13:33, wrote:
>> On 15/03/2019 10:47, Jan Beulich wrote:
>>> @@ -9312,7 +9386,8 @@ x86_emulate(
>>>
>>> if ( ea.type == OP_MEM )
>>> {
>>> -rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, 8 << vex.l,
>>> c
On 15/03/2019 10:54, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
With the identified issue fixed, Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/03/2019 10:55, Jan Beulich wrote:
> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>
> Note that despite the replacement of the SHA insns' table slots there's
> no need to special case their decoding: Their insn-specific code already
> sets op_bytes (as was required due to simd_
flight 136860 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136860/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 136859 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136859/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-rimava1 2 hosts-allocate starved n/a
examine-rochester02 hosts-allocate
Instead of ignoring xen.lds and asm-offsets.s for every specific arch,
let's instead just use gitignore's wildcard feature to ignore them for
all archs.
Signed-off-by: Alistair Francis
---
.gitignore | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/.gitignore b/.gitignor
Following the recent discussion, we had on IRC and the action I had in
the March community call, this file provides a file format that
enables writing an automated test to check whether files are out of sync.
Once the file format is agree, I will write a test or script.
I also need some more c
flight 136732 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
build-i386-prev
flight 136728 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136728/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 136233
test-amd64-amd64-libvirt 13
flight 136726 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858
test-amd64-i386-xl-q
Hi,
I met some python related issues when building Xen on RedHat8.0.
On RedHat8.0, the default python version is python3, and I found Xen has some
python2 codes, so I tried to build xen using python2.
On RedHat8.0, no "python", just "python2" and "python3":
ls /usr/bin/python*
/usr/bin/python2
On 22/05/2019 12:10, Jan Beulich wrote:
On 22.05.19 at 11:45, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>
>> ASSERT(is_hvm_vcpu(v));
>>
>> -/*
>> - * XXX Disable for 4.1.0:
flight 136739 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 136249
Tests which did not s
>>> On 24.05.19 at 07:41, wrote:
> On 22/05/2019 12:10, Jan Beulich wrote:
> On 22.05.19 at 11:45, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>>
>>> ASSERT(is_hvm_vcpu(v));
>>>
>>
>>> On 23.05.19 at 18:15, wrote:
> On 15/03/2019 10:55, Jan Beulich wrote:
>> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>>
>> Note that despite the replacement of the SHA insns' table slots there's
>> no need to special case their decoding: Their insn-specific code already
>> se
70 matches
Mail list logo
