On 26/11/2018 21:11, Boris Ostrovsky wrote:
> On 11/23/18 11:24 AM, Juergen Gross wrote:
>> Failure of an element of a Xen multicall is signalled via a WARN()
>> only unless the kernel is compiled with MC_DEBUG. It is impossible to
>
> s/unless/if
>
>
>> know which element failed and why it did
On 26/11/2018 17:50, Jan Beulich wrote:
On 26.11.18 at 17:17, wrote:
>> I really fail to see why it is so bad to not clobber data in a case
>> which normally should never occur.
>
> See Andrew's original reply. You're also clobbering on potential
> success paths.
I think you are missing a
On 26/11/2018 17:51, Julien Grall wrote:
>
>
> On 26/11/2018 16:17, Juergen Gross wrote:
>> On 26/11/2018 17:01, Julien Grall wrote:
>>>
>>>
>>> On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
>> On 26/11/2018
On 11/26/18 2:57 PM, Igor Druzhinin wrote:
> On 26/11/2018 19:42, Boris Ostrovsky wrote:
>> On 11/26/18 12:10 PM, Igor Druzhinin wrote:
>>> On 26/11/2018 16:25, Boris Ostrovsky wrote:
On 11/25/18 8:00 PM, Igor Druzhinin wrote:
> On 20/12/2017 14:05, Boris Ostrovsky wrote:
>> Commit
flight 130773 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> On 11/21/18 9:07 PM, Pan Bian wrote:
> > kfree() is incorrectly used to release the pages allocated by
> > __get_free_page() and __get_free_pages(). Use the matching deallocators
> > i.e., free_page() and free_pages(),
Hi,
I wanted to install Xen from source on Fedora 28.
I choose the stable-4.11 branch, compiled it, and got an error at
sudo make install
make[7]: Entering directory
'/home/vagrant/xen/tools/firmware/seabios-dir-remote'
Compiling IASL src/fw/ssdt-misc.hex
out/src/fw/ssdt-misc.dsl.i 4:
flight 130765 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On 11/21/18 9:07 PM, Pan Bian wrote:
> kfree() is incorrectly used to release the pages allocated by
> __get_free_page() and __get_free_pages(). Use the matching deallocators
> i.e., free_page() and free_pages(), respectively.
>
> Signed-off-by: Pan Bian
> ---
> drivers/xen/pvcalls-front.c | 4
flight 130819 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130819/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 11/23/18 11:24 AM, Juergen Gross wrote:
> Failure of an element of a Xen multicall is signalled via a WARN()
> only unless the kernel is compiled with MC_DEBUG. It is impossible to
s/unless/if
> know which element failed and why it did so.
>
> Change that by printing the related information
Hi
On Mon, Nov 26, 2018 at 5:27 PM Igor Mammedov wrote:
>
> On Wed, 7 Nov 2018 16:36:48 +0400
> Marc-André Lureau wrote:
>
> > It's now possible to use the common function.
> >
> > Teach object_apply_global_props() to warn if Error argument is NULL.
> >
> > Signed-off-by: Marc-André Lureau
> >
flight 130768 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On 26/11/2018 19:42, Boris Ostrovsky wrote:
> On 11/26/18 12:10 PM, Igor Druzhinin wrote:
>> On 26/11/2018 16:25, Boris Ostrovsky wrote:
>>> On 11/25/18 8:00 PM, Igor Druzhinin wrote:
On 20/12/2017 14:05, Boris Ostrovsky wrote:
> Commit f5775e0b6116 ("x86/xen: discard RAM regions above
flight 130758 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances, thus turning
the following condition:
if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE )
Into:
0x82d080223967 <+103>: cmpl
On Wed, Nov 21, 2018 at 5:08 PM Andrew Cooper wrote:
>
> On 21/11/2018 22:42, Tamas K Lengyel wrote:
> > On Wed, Nov 21, 2018 at 2:22 PM Andrew Cooper
> > wrote:
> >> On 21/11/2018 17:19, Tamas K Lengyel wrote:
> >>> On Wed, Nov 21, 2018 at 6:21 AM Andrew Cooper
> >>> wrote:
> This
The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
to be specified as ignored. However, bits 5 and 6 are now specified as
'accessed' and 'dirty' bits and their use only remains safe as long as
the DTE 'Host Access Dirty' bits remain clear. The code is also of dubious
flight 130814 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130814/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 130289
Tests which
On 26/11/2018 16:25, Boris Ostrovsky wrote:
> On 11/25/18 8:00 PM, Igor Druzhinin wrote:
>> On 20/12/2017 14:05, Boris Ostrovsky wrote:
>>> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
>>> reservation") left host memory not assigned to dom0 as available for
>>> memory
On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
I don't think the
>>> On 26.11.18 at 17:17, wrote:
> I really fail to see why it is so bad to not clobber data in a case
> which normally should never occur.
See Andrew's original reply. You're also clobbering on potential
success paths.
Jan
___
Xen-devel mailing
On 11/25/18 8:00 PM, Igor Druzhinin wrote:
> On 20/12/2017 14:05, Boris Ostrovsky wrote:
>> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
>> reservation") left host memory not assigned to dom0 as available for
>> memory hotplug.
>>
>> Unfortunately this also meant that those
On Mon, Nov 26, 2018 at 08:50:14AM -0700, Jan Beulich wrote:
> A top level "make build", as used e.g. by osstest, wants to build all
> "all" targets in enabled tools subdirectories, which by default also
> includes the emulator test harness. The use of, in particular, {evex}
> insn pseudo-prefixes
On 26/11/2018 17:01, Julien Grall wrote:
>
>
> On 26/11/2018 15:29, Juergen Gross wrote:
>> On 26/11/2018 15:58, Jan Beulich wrote:
>> On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should
>>> On 26.11.18 at 17:03, wrote:
> Am Mon, 26 Nov 2018 03:31:27 -0700
> schrieb "Jan Beulich" :
>
>> And I think a change like this should (a) address the more general
>> case rather than just your laptop (or laptops in general) and (b)
>> actually add some headroom. Hence at the very least I'd
On Mon, Nov 26, 2018 at 03:38:52PM +, Paul Durrant wrote:
> Whilst attempting to crash an apparently wedged Windows domain using
> 'xen-hvmcrash' I managed to trigger the following ASSERT:
>
> (XEN) Assertion '!vp->ptr' failed at viridian.c:607
>
> with stack:
>
> (XEN)[]
Am Mon, 26 Nov 2018 03:31:27 -0700
schrieb "Jan Beulich" :
> And I think a change like this should (a) address the more general
> case rather than just your laptop (or laptops in general) and (b)
> actually add some headroom. Hence at the very least I'd see us
> go to 4096x3072. WHUXGA would even
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find
On 26.11.18 15:20, Michal Suchánek wrote:
> On Mon, 26 Nov 2018 14:33:29 +0100
> David Hildenbrand wrote:
>
>> On 26.11.18 13:30, David Hildenbrand wrote:
>>> On 23.11.18 19:06, Michal Suchánek wrote:
>
If we are going to fake the driver information we may as well add the
type
On Wed, Nov 21, 2018 at 01:21:18PM +, Andy Cooper wrote:
> Seemingly, a majority of users either override the helpers anyway, or have an
> gfn_t in their hands.
>
> Update the API, and adjust all users to match.
>
> Doing this highlighted a gaping altp2m security hole in
>
Juergen Gross writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 26/11/2018 15:54, Ian Jackson wrote:
> > Maybe they could be clobbered losslessly ? Eg, by xoring with 0xaa or
> > something.
>
> This would be rather hacky: I'd need to find out if clobbering was
>
A top level "make build", as used e.g. by osstest, wants to build all
"all" targets in enabled tools subdirectories, which by default also
includes the emulator test harness. The use of, in particular, {evex}
insn pseudo-prefixes in, again in particular, test_x86_emulator.c causes
this build to
Whilst attempting to crash an apparently wedged Windows domain using
'xen-hvmcrash' I managed to trigger the following ASSERT:
(XEN) Assertion '!vp->ptr' failed at viridian.c:607
with stack:
(XEN)[] viridian_map_guest_page+0x1b4/0x1b6
(XEN)[] viridian_synic_load_vcpu_ctxt+0x39/0x3b
On Thu, 22 Nov 2018 00:27:33 +0100
Samuel Ortiz wrote:
> On Thu, Nov 15, 2018 at 02:28:54PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:38 +0100
> > Samuel Ortiz wrote:
> >
> > > This is the standard way of building SRAT on x86 platfoms. But future
> > > machine types could
> -Original Message-
> From: Roger Pau Monne
> Sent: 26 November 2018 15:32
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; Wei Liu
> Subject: Re: [PATCH] viridian: fix assertion failure
>
> On Mon, Nov 26, 2018 at 03:08:50PM +, Paul Durrant
On Mon, Nov 26, 2018 at 09:35:26AM -0600, Brian Woods wrote:
> On Mon, Nov 26, 2018 at 09:05:25AM +, Paul Durrant wrote:
> > Bring the coding style up to date. No functional change.
> >
> > Signed-off-by: Paul Durrant
>
> Acked-by: Brian Woods
>
> --
> Brian Woods
Meant for another
On Mon, Nov 26, 2018 at 03:08:50PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 26 November 2018 15:04
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> > Andrew Cooper ; Wei Liu
> > Subject: Re: [PATCH] viridian: fix
On Mon, Nov 26, 2018 at 09:05:25AM +, Paul Durrant wrote:
> Bring the coding style up to date. No functional change.
>
> Signed-off-by: Paul Durrant
Acked-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
>> On 26/11/2018 15:01, Jan Beulich wrote:
>> On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find problems in the code.
>>>
>>>
On Thu, Nov 15, 2018 at 09:47:17PM +, Andy Cooper wrote:
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
>
On 26/11/2018 15:54, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
> error"):
>> On 23.11.18 at 14:25, wrote:
>>> In debug builds the hypervisor will deliberately clobber processed
>>> elements of the multicall structure. In order to ease
On Mon, Nov 26, 2018 at 04:04:08PM +0100, Olaf Hering wrote:
> Am Mon, 26 Nov 2018 15:58:22 +0100
> schrieb Olaf Hering :
>
> > +++ b/tools/xl/xl.c
> > @@ -229,6 +229,9 @@ static void parse_global_config(const char *configfile,
>
> Actually I think that should go to xl_ctx_free() instead. I
> -Original Message-
> From: Roger Pau Monne
> Sent: 26 November 2018 15:04
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; Wei Liu
> Subject: Re: [PATCH] viridian: fix assertion failure
>
> On Mon, Nov 26, 2018 at 02:54:54PM +, Paul Durrant
On Mon, Nov 26, 2018 at 02:54:54PM +, Paul Durrant wrote:
> Whilst attempting to crash an apparently wedged Windows domain using
> 'xen-hvmcrash' I managed to trigger the following ASSERT:
>
> (XEN) Assertion '!vp->ptr' failed at viridian.c:607
>
> with stack:
>
> (XEN)[]
Am Mon, 26 Nov 2018 15:58:22 +0100
schrieb Olaf Hering :
> +++ b/tools/xl/xl.c
> @@ -229,6 +229,9 @@ static void parse_global_config(const char *configfile,
Actually I think that should go to xl_ctx_free() instead. I moved it down to
parse_global_config() by accident.
Olaf
pgptRsIXARFmB.pgp
>>> On 26.11.18 at 15:23, wrote:
> On 26/11/2018 15:01, Jan Beulich wrote:
> On 26.11.18 at 14:52, wrote:
>>> I don't think the hypervisor should explicitly try to make it as hard as
>>> possible for the guest to find problems in the code.
>>
>> That's indeed not the hypervisor's goal.
Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 23.11.18 at 14:25, wrote:
> > In debug builds the hypervisor will deliberately clobber processed
> > elements of the multicall structure. In order to ease diagnostic data
> > printout in the affected
Whilst attempting to crash an apparently wedged Windows domain using
'xen-hvmcrash' I managed to trigger the following ASSERT:
(XEN) Assertion '!vp->ptr' failed at viridian.c:607
with stack:
(XEN)[] viridian_map_guest_page+0x1b4/0x1b6
(XEN)[] viridian_synic_load_vcpu_ctxt+0x39/0x3b
On Fri, Nov 23, 2018 at 04:57:08PM +0100, Olaf Hering wrote:
> Am Fri, 23 Nov 2018 15:54:49 +
> schrieb Anthony PERARD :
>
> > Is your toolstack runs the QMP command 'query-block' or some other
> > command related to block behind libxl's back?
>
> This is plain xl create + xl migrate from
On Fri, Nov 23, 2018 at 11:30:39PM +0800, Mao Zhongyi wrote:
> The init function doesn't do anything at all, so we
> just omit it.
>
> Cc: sstabell...@kernel.org
> Cc: anthony.per...@citrix.com
> Cc: xen-devel@lists.xenproject.org
> Cc: peter.mayd...@linaro.org
>
> Signed-off-by: Mao Zhongyi
>
On Mon, Nov 26, 2018 at 07:13:33AM -0700, Jan Beulich wrote:
> When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
> 32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
> instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
> switch
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should explicitly try to make it as hard as
>> possible for the guest to find problems in the code.
>
> That's indeed not the hypervisor's goal. Instead it tries to make
> it as hard as
flight 130811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130811/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 130289
Tests which
On Mon, 26 Nov 2018 14:33:29 +0100
David Hildenbrand wrote:
> On 26.11.18 13:30, David Hildenbrand wrote:
> > On 23.11.18 19:06, Michal Suchánek wrote:
> >>
> >> If we are going to fake the driver information we may as well add the
> >> type attribute and be done with it.
> >>
> >> I think
On 26/11/2018 14:13, Jan Beulich wrote:
> When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
> 32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
> instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
> switch around the use in the
When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
switch around the use in the expression controlling the rule
dependencies,
>>> On 26.11.18 at 14:52, wrote:
> I don't think the hypervisor should explicitly try to make it as hard as
> possible for the guest to find problems in the code.
That's indeed not the hypervisor's goal. Instead it tries to make
it as hard as possible for the guest (developer) to make wrong
On Wed, 7 Nov 2018 16:36:38 +0400
Marc-André Lureau wrote:
> Hi,
>
> During "[PATCH v2 05/10] qom/globals: generalize
> object_property_set_globals()" review, Eduardo suggested to rework the
> GlobalProperty handling, so that -global is limited to QDev only and
> we avoid mixing the machine
On 26/11/2018 11:58, Jan Beulich wrote:
On 23.11.18 at 14:25, wrote:
>> In debug builds the hypervisor will deliberately clobber processed
>> elements of the multicall structure. In order to ease diagnostic data
>> printout in the affected guest only clobber elements which didn't
>> return
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 26 November 2018 13:41
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] x86_emulator distclean failing
>
> >>> On 26.11.18 at 14:04, wrote:
> > Anyone
>>> On 26.11.18 at 14:04, wrote:
> Anyone else seeing this, or is it just me? This was on a fresh pull of
> staging about 5 mins ago...
I don't think I ever ran distclean, but I think I can see the issue.
Would you mind trying
--- a/tools/tests/x86_emulator/Makefile
+++
On 26.11.18 13:30, David Hildenbrand wrote:
> On 23.11.18 19:06, Michal Suchánek wrote:
>> On Fri, 23 Nov 2018 12:13:58 +0100
>> David Hildenbrand wrote:
>>
>>> On 28.09.18 17:03, David Hildenbrand wrote:
How to/when to online hotplugged memory is hard to manage for
distributions
>>> On 23.11.18 at 17:52, wrote:
> RFC, as I expect this patch to get some objection for removing the IRQ safety
> check, but the only reasons that change was made in e5fc6434d7 was because I
> talk talked into doing it while trying to clean up some unnecessary use of
> magic numbers.
>
> No
There is a circular link formed between domain and a connection. In certain
circustances, when conn is freed, domain is also freed, which leads to use
after free when trying to set the conn field in domain to null.
Signed-off-by: Petre Eftime
---
tools/xenstore/xenstored_domain.c | 9 -
>>> On 23.11.18 at 17:52, wrote:
> ... rather than a macro which writes to its parameter by name. Take the
> opportunity to fold the assignment into the flags declaraion where
> appropriate.
Do you really? Why not ...
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -401,7 +401,7 @@
On Wed, 7 Nov 2018 16:36:48 +0400
Marc-André Lureau wrote:
> It's now possible to use the common function.
>
> Teach object_apply_global_props() to warn if Error argument is NULL.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/core/qdev-properties.c | 24 ++--
>
>>> On 23.11.18 at 17:52, wrote:
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -253,14 +253,18 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> /* used when interrupts are already enabled or to shutdown the processor */
> #define
Anyone else seeing this, or is it just me? This was on a fresh pull of staging
about 5 mins ago...
make -C x86_emulator distclean
make[5]: Entering directory '/local/scratch/pauldu/xen/tools/tests/x86_emulator'
make -C 32 clean
make[6]: Entering directory
>>> On 23.11.18 at 17:52, wrote:
> No functional change, as the value returned was previously always 0 or 1.
> While altering these, insert blank lines where appropriate and drop the
> now-redundant !! from x86's local_irq_is_enabled().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
>>> On 26.11.18 at 13:49, wrote:
> On Mon, Nov 26, 2018 at 05:18:20AM -0700, Jan Beulich wrote:
>> Furthermore I doubt writing this down would help, because for
>> such apparently simple things no-one goes hunt for related
>> documentation. I think the only future proof course of action
>> would
>>> On 22.11.18 at 12:40, wrote:
> change_range_type() invalidates gfn ranges to lazily change the type
Would you mind correcting the function name here?
> of a range of gfns, and also modifies the logdirty rangesets of that
> p2m. At the moment, it clips both down by the hostp2m.
>
> While
On Mon, Nov 26, 2018 at 05:18:20AM -0700, Jan Beulich wrote:
> >>> On 26.11.18 at 13:04, wrote:
> > On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
> >> >>> On 23.11.18 at 15:30, wrote:
> >> > LLVM code generation can attempt to load from a variable in the next
> >> > condition of
>>> On 26.11.18 at 13:17, wrote:
> On Mon, Nov 26, 2018 at 12:03:07PM +, Andrew Cooper wrote:
>> c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
>> introduced a TypeError when changing how Fail exceptions were printed:
>>
>>
>>> On 26.11.18 at 13:25, wrote:
> May I ask what are the downsides? Do you expect a lot of false positive?
Having to split code paths, to introduce redundancy, or to move
code/data out of .init.* that could in fact live there are all
possible issues. Plus the __ref{,data} annotation that Linux
flight 130752 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130752/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 23.11.18 19:06, Michal Suchánek wrote:
> On Fri, 23 Nov 2018 12:13:58 +0100
> David Hildenbrand wrote:
>
>> On 28.09.18 17:03, David Hildenbrand wrote:
>>> How to/when to online hotplugged memory is hard to manage for
>>> distributions because different memory types are to be treated
On Mon, Nov 26, 2018 at 10:40:44AM +, Wei Liu wrote:
> Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
> xen-init-dom0 accept an extra argument for UUID.
>
> Also switch xs_open error message to use perror.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Juergen Gross
>
>>> On 20.11.18 at 15:37, wrote:
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
> presence of the MSR.
>
>
>>> On 26.11.18 at 13:04, wrote:
> On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
>> >>> On 23.11.18 at 15:30, wrote:
>> > LLVM code generation can attempt to load from a variable in the next
>> > condition of an expression under certain circumstances, thus turning
>> > the
On Mon, Nov 26, 2018 at 12:03:07PM +, Andrew Cooper wrote:
> c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
> introduced a TypeError when changing how Fail exceptions were printed:
>
> /local/xen.git/xen/../xen/tools/gen-cpuid.py:Traceback (most recent call
> last):
Hello, all!
My driver (Xen para-virtualized frontend) in some scenarios uses
drm_gem_get_pages for allocating backing storage for dumb buffers.
There are use-cases which showed some artifacts on the screen
(modetest, other) which were worked around by flushing pages of the
buffer on page flip
>>> On 22.11.18 at 12:40, wrote:
> @@ -956,18 +1003,14 @@ int p2m_change_type_one(struct domain *d, unsigned
> long gfn_l,
> }
>
> /* Modify the p2m type of a range of gfns from ot to nt. */
> -void p2m_change_type_range(struct domain *d,
> - unsigned long start,
>>> On 22.11.18 at 12:40, wrote:
> The logdirty rangesets of the altp2ms need to be kept in sync with the
> hostp2m. This means when iterating through the altp2ms, we need to
> use the host p2m to clip the rangeset, not the indiviual altp2m's
> value.
>
> This change also:
>
> - Documents that
On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
> >>> On 23.11.18 at 15:30, wrote:
> > LLVM code generation can attempt to load from a variable in the next
> > condition of an expression under certain circumstances, thus turning
> > the following condition:
> >
> > if ( system_state
c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
introduced a TypeError when changing how Fail exceptions were printed:
/local/xen.git/xen/../xen/tools/gen-cpuid.py:Traceback (most recent call
last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 483, in
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 11:42
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 11:49
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v2 2/2] amd-iommu: replace occurrences of
> u with
>>> On 26.11.18 at 12:32, wrote:
> @@ -306,7 +307,8 @@ void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64
> gcr3,
> uint64_t amd_iommu_get_address_from_pte(void *pte)
> {
> uint32_t *entry = pte;
> -uint64_t addr_lo, addr_hi, ptr;
> +uint32_t addr_lo, addr_hi;
> +uint64_t
>>> On 20.11.18 at 17:01, wrote:
> Current logic to handle long running operations is flawed because it
> doesn't prevent the guest vcpu from running. Fix this by raising a
> scheduler softirq when preemption is required, so that the do_softirq
> call in the guest entry path performs a
Bring the coding style up to date. No functional change (except for
removal of some pointless initializers).
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 26 +-
1 file
...for N in {8, 16, 32, 64}.
Bring the coding style up to date.
Also, while in the neighbourhood, fix some tabs and remove use of uint64_t
values where it leads to the need for explicit casting.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
v2:
- Remove some
Paul Durrant (2):
amd-iommu: replace occurrences of bool_t with bool
amd-iommu: replace occurrences of u with uint_t...
xen/drivers/passthrough/amd/iommu_map.c | 148 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
2 files changed, 77 insertions(+),
>>> On 20.11.18 at 17:01, wrote:
> No functional change expected.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 130808 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6
>>> On 20.11.18 at 17:01, wrote:
> Current logic to handle long running operations is flawed because it
> doesn't prevent the guest vcpu from running. Fix this by raising a
> scheduler softirq when preemption is required, so that the do_softirq
> call in the guest entry path performs a
osstest service owner writes ("[osstest test] 130741: regressions - FAIL"):
> flight 130741 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/130741/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
>>> On 20.11.18 at 17:01, wrote:
> When switching the memory decoding bit in the command register the
> rest of the changes where dropped, leading to only the memory decoding
> bit being updated.
>
> Fix this by writing the command register once the guest physmap
> manipulations are done if
>>> On 23.11.18 at 14:25, wrote:
> In debug builds the hypervisor will deliberately clobber processed
> elements of the multicall structure. In order to ease diagnostic data
> printout in the affected guest only clobber elements which didn't
> return an error.
Besides what Andrew has said such a
flight 75621 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75589
1 - 100 of 119 matches
Mail list logo
