>>> Ian Jackson 03/07/19 4:44 PM >>>
>Jan Beulich writes ("Re: [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for
>uintptr_t"):
>> On 06.03.19 at 22:16, wrote:
>> > Also, it is not a good idea to use __mode__(__pointer__) to define
>> > uintptr_t, because it relies on an obscurely defined GCC
>>> George Dunlap 03/07/19 1:02 PM >>>
>On 3/7/19 10:34 AM, Jan Beulich wrote:
>> While I've not observed this myself, gcc 9 (imo validly) reportedly may
>> complain
>>
>> trace.c: In function '__trace_hypercall':
>> trace.c:826:19: error: taking address of packed member of 'struct
>> ' may
On 07/03/2019 19:00, Julien Grall wrote:
> Hi Roger,
>
> On 07/03/2019 17:15, Roger Pau Monné wrote:
>> On Thu, Mar 07, 2019 at 04:36:59PM +, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> Thank you for the answer.
>>>
>>> On 07/03/2019 16:16, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at
This run is configured for baseline tests only.
flight 83718 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/83718/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 133616 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133616/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 33436807929738dccab4da85728a5b11458d1bca
baseline version:
freebsd
flight 133613 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133613/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133589
flight 133611 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133611/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 129313
flight 133612 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133612/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133582
test-armhf-armhf-libvirt-raw 13
On Thu, 7 Mar 2019, Ian Jackson wrote:
> bug_frames
> --
>
> What appears to be going on is this:
>
> setup_virtual_regions contains a static const array of pointers to
> struct bug_frame. These struct bug_frame* values are themselves
> linker symbol values.
>
> Because the compiler
On Thu, Mar 07, 2019 at 03:48:01PM +0100, Roger Pau Monné wrote:
> On Thu, Mar 07, 2019 at 01:50:04AM +0100, Marek Marczykowski-Górecki wrote:
> > On Fri, Feb 22, 2019 at 11:42:22AM +0100, Roger Pau Monné wrote:
> > > On Thu, Feb 21, 2019 at 06:40:40PM +0100, Marek Marczykowski-Górecki
> > >
This run is configured for baseline tests only.
flight 83717 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83717/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On Thu, 7 Mar 2019, Julien Grall wrote:
> On 07/03/2019 08:42, Amit Tomer wrote:
> > Hi,
> >
> > > Not really, the DT provided by Amit is for the host. The memory node
> > > will be rewritten by Xen for Dom0 and does not include the
> > > reserved-memory regions so far.
> > >
> > Thanks for
From: Volodymyr Babchuk
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator needs to do address translation in the same
way as it was done for shared buffers registered by NW.
OP-TEE can ask
From: Volodymyr Babchuk
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
From: Volodymyr Babchuk
Shared memory is widely used by NW (Normal World) to communicate with
TAs (Trusted Applications) in OP-TEE. NW can share part of own memory
with TA or with OP-TEE core, by registering it in OP-TEE, or by
providing a temporal reference. Anyways, information about such
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'native'.
'none' is the default value and it basically disables TEE support at
all.
'native' enables access to a "real" TEE installed on a platform.
It is
From: Volodymyr Babchuk
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and forward all known
calls.
This is all what is needed for Dom0 to work with OP-TEE as long as
Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
From: Volodymyr Babchuk
If TEE support is enabled with "tee=native" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr Babchuk
---
This
From: Volodymyr Babchuk
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contrast with fast calls, where arguments and return values
From: Volodymyr Babchuk
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP-TEE memory with a domain.
Only domain
From: Volodymyr Babchuk
Hello all,
This is the 4th version of TEE mediator patch series. In the meantime
virtualization support were merged into OP-TEE mainline.
Last time our mail server changed order of messages in the mail thread.
I hope, this time it will send them in the right way. But,
From: Volodymyr Babchuk
This header files describes protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC
flight 133609 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133583
Hi Roger,
On 07/03/2019 17:15, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 04:36:59PM +, Julien Grall wrote:
Hi Roger,
Thank you for the answer.
On 07/03/2019 16:16, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 03:17:54PM +, Julien Grall wrote:
Hi Andrii,
On 07/03/2019 14:34,
> -Original Message-
> From: Roger Pau Monne
> Sent: 07 March 2019 17:41
> To: Paul Durrant
> Cc: xen-devel (xen-devel@lists.xenproject.org)
>
> Subject: Re: [Xen-devel] standalone PCI passthrough emulator
>
> On Fri, Mar 01, 2019 at 04:41:25PM +, Paul Durrant wrote:
> > Hi,
> >
>
On Fri, Mar 01, 2019 at 04:41:25PM +, Paul Durrant wrote:
> Hi,
>
> As the basis of some future development work I've put together a simple
> standalone emulator to pass through a single type 0 PCI function to a guest
> so I'm posting here in case anyone else would like a give it a try.
On Thu, Mar 07, 2019 at 04:36:59PM +, Julien Grall wrote:
> Hi Roger,
>
> Thank you for the answer.
>
> On 07/03/2019 16:16, Roger Pau Monné wrote:
> > On Thu, Mar 07, 2019 at 03:17:54PM +, Julien Grall wrote:
> > > Hi Andrii,
> > >
> > > On 07/03/2019 14:34, Andrii Anisov wrote:
> > >
flight 133610 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133610/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8ef3a6ec1f6a858bb14c40715db90c1e3927cced
baseline version:
ovmf
Hi Roger,
Thank you for the answer.
On 07/03/2019 16:16, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 03:17:54PM +, Julien Grall wrote:
Hi Andrii,
On 07/03/2019 14:34, Andrii Anisov wrote:
On 07.03.19 16:02, Julien Grall wrote:
- IMHO, this implementation is simpler and cleaner
On Thu, Mar 07, 2019 at 03:17:54PM +, Julien Grall wrote:
> Hi Andrii,
>
> On 07/03/2019 14:34, Andrii Anisov wrote:
> > On 07.03.19 16:02, Julien Grall wrote:
> > > > - IMHO, this implementation is simpler and cleaner than what I
> > > > have for runstate mapping on access.
> > >
> > >
Jan Beulich writes ("Re: [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for
uintptr_t"):
> On 06.03.19 at 22:16, wrote:
> > Also, it is not a good idea to use __mode__(__pointer__) to define
> > uintptr_t, because it relies on an obscurely defined GCC feature whose
> > semantics might be taken to
flight 133605 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 133580
Tests which did
Stefano Stabellini writes ("[PATCH v11 9/9] xen: explicit casts when
DECLARE_BOUNDS cannot be used"):
> Sometimes the static inline functions provided by DECLARE_BOUNDS cannot
> be used. This patch uses explicit casts to uintptr_t in those cases.
>
> M3CM: Rule-18.2: Subtraction between pointers
On 07/03/2019 15:17, Julien Grall wrote:
Hi Andrii,
On 07/03/2019 14:34, Andrii Anisov wrote:
On 07.03.19 16:02, Julien Grall wrote:
So I assume you say about you preferences to not have runstate area mapped
because of consuming vmap space for arm64. Also, along that thread you
mentioned
Hi Andrii,
On 07/03/2019 14:34, Andrii Anisov wrote:
On 07.03.19 16:02, Julien Grall wrote:
So I assume you say about you preferences to not have runstate area mapped
because of consuming vmap space for arm64. Also, along that thread you
mentioned you that guest might change gva mapping, what
On Thu, Mar 07, 2019 at 01:50:04AM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 22, 2019 at 11:42:22AM +0100, Roger Pau Monné wrote:
> > On Thu, Feb 21, 2019 at 06:40:40PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Feb 21, 2019 at 05:47:51PM +0100, Roger Pau Monné wrote:
> >
Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> I'd like to note though that in the first two cases we don't alter the
> declared object anyway, but instead a derived one; the declaration
> should not use const for other reasons though. And the 3rd case is
>
On 3/7/19 2:02 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS
> as required"):
>> On Wed, 6 Mar 2019, Jan Beulich wrote:
>>> Is the line wrapping really needed here?
>>
>> It would end at 80 characters exactly otherwise. I am happy to do as
On 07.03.19 16:02, Julien Grall wrote:
So I assume you say about you preferences to not have runstate area mapped
because of consuming vmap space for arm64. Also, along that thread you
mentioned you that guest might change gva mapping, what is irrelevant to
registration with physical
Hi Lukasz
On Wed, Mar 06, 2019 at 11:21:22AM +, Hawrylko, Lukasz wrote:
> Due to personal changes at Intel, I am new TXT maintainer for XEN.
> Adding patch that updates maintainers list.
>
> Thanks,
> Lukasz
Unfortunately your patch needs fixing. The form is not correct.
I would suggest
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
On Thu, Mar 07, 2019 at 04:22:13AM -0700, Jan Beulich wrote:
> >>> On 07.03.19 at 11:55, wrote:
> > On Thu, Mar 07, 2019 at 03:32:12AM -0700, Jan Beulich wrote:
> >> generic.c: In function ‘print_mtrr_state’:
> >> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
> >>
Jan Beulich writes ("Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS"):
> On 06.03.19 at 21:55, wrote:
> > On Wed, 6 Mar 2019, Jan Beulich wrote:
> > uintptr_t is the integer type corresponding to a pointer, so we should
> > use uintptr_t first. ptrdiff_t is the difference type so we should
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the
This series adds three new enlightenments:
- Synthetic timers, which depends on the...
- Synthetic interrupt controller (or SynIC)
- Synthetic cluster IPI
All these enlightenments are implemented in current versions of QEMU/KVM
so this series closes the gap.
Paul Durrant (11):
viridian: add
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
NOTE: This patch also removes the call from the domain deinit function to
the vcpu deinit function, as this is not necessary.
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
flight 133602 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-amd64-i386-examine 8 reboot
On 07/03/2019 13:01, Andrii Anisov wrote:
Dear Julien,
Hello,
On 05.03.19 15:56, Julien Grall wrote:
I had some concern about this solution in [1] that have not been addressed nor
even mentioned in the series.
You missed the link.
I was referring to your [1].
So I assume you say about
Stefano Stabellini writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> On Wed, 6 Mar 2019, Jan Beulich wrote:
> > Is the line wrapping really needed here?
>
> It would end at 80 characters exactly otherwise. I am happy to do as you
> prefer.
Certainly I prefer lines to end
Stefano Stabellini writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> This is problematic. We have also the following instances in this series
> to deal with:
>
> xen/arch/arm/percpu.c:_free_percpu_area
> char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];
>
>
On 07/03/2019 13:32, Tamas K Lengyel wrote:
> Hi all,
> just want to report the following crash with dom0=pvh command line
> option enabled with 4.12-rc4:
>
> ...
> [ OK ] Found device /dev/hvc0.
> [ 49.841991] input: HDA ATI HDMI HDMI/DP,pcm=3 as
>
Hi all,
just want to report the following crash with dom0=pvh command line
option enabled with 4.12-rc4:
...
[ OK ] Found device /dev/hvc0.
[ 49.841991] input: HDA ATI HDMI HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6
[ 49.842056] input: HDA ATI HDMI
On 05.03.19 16:30, Julien Grall wrote:
On 3/5/19 2:11 PM, Andrii Anisov wrote:
It is not an annoyance, but inaccurate runstate info passed (actually not
passed) to KPTI enabled guests.
The runstate is actually updated just not for the guest.
That is what I said.
It will be done at the
Dear Julien,
On 05.03.19 15:56, Julien Grall wrote:
I had some concern about this solution in [1] that have not been addressed nor
even mentioned in the series.
You missed the link.
So I assume you say about you preferences to not have runstate area mapped
because of consuming vmap space
Jan,
We've noticed that there is still a regression with p2m_ioreq_server P2M
type on master. Since the commit 940faf0279 (x86/HVM: split page
straddling emulated accesses in more cases) the behavior of write and
rmw instruction emulation changed (possibly unintentionally) so that it
might not
flight 133603 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
On Thu, Mar 07, 2019 at 12:53:38PM +0100, Olaf Hering wrote:
> Am Thu, 7 Mar 2019 11:02:47 +
> schrieb Wei Liu :
>
> > Have you seen the field been set before entering this function? Or is
> > the if () just a precaution?
>
> Sorry, this is not the variant I intended to send.
> The
flight 83715 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/83715/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 3/7/19 10:34 AM, Jan Beulich wrote:
> While I've not observed this myself, gcc 9 (imo validly) reportedly may
> complain
>
> trace.c: In function '__trace_hypercall':
> trace.c:826:19: error: taking address of packed member of 'struct
> ' may result in an unaligned pointer value
>
>>> On 07.03.19 at 12:37, wrote:
> On Thu, 7 Mar 2019, Jan Beulich wrote:
>
>> Several build issues (new warnings, causing the build to fail due to
>> -Werror) have been found. The two changes here address the ones
>> I can actually repro; there are a few more related to
>>
Am Thu, 7 Mar 2019 11:02:47 +
schrieb Wei Liu :
> Have you seen the field been set before entering this function? Or is
> the if () just a precaution?
Sorry, this is not the variant I intended to send.
The assignment was supposed to be unconditionally.
Today I browsed the code and it was
>>> On 07.03.19 at 12:40, wrote:
> On 07/03/2019 10:34, Jan Beulich wrote:
>> While I've not observed this myself, gcc 9 (imo validly) reportedly may
>> complain
>>
>> trace.c: In function '__trace_hypercall':
>> trace.c:826:19: error: taking address of packed member of 'struct
>> ' may result
>>> On 05.03.19 at 23:38, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -976,7 +976,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> * respective reserve_e820_ram() invocation below.
> */
> mod[mbi->mods_count].mod_start =
On 07/03/2019 10:34, Jan Beulich wrote:
> While I've not observed this myself, gcc 9 (imo validly) reportedly may
> complain
>
> trace.c: In function '__trace_hypercall':
> trace.c:826:19: error: taking address of packed member of 'struct
> ' may result in an unaligned pointer value
>
On Thu, 7 Mar 2019, Jan Beulich wrote:
> Several build issues (new warnings, causing the build to fail due to
> -Werror) have been found. The two changes here address the ones
> I can actually repro; there are a few more related to
> -Waddress-of-packed-member which I haven't been able to see
>
On Thu, Mar 07, 2019 at 10:37:45AM +, Wei Liu wrote:
>
> Importing print_function was specifically avoided because we wanted 2.4
> compatibility at first. But now I propose to bump the requirement to
> 2.6, the from __future__ import print_function may become available. I
> will need to check
On Thu, Mar 07, 2019 at 11:21:29AM +, Anthony PERARD wrote:
> On Wed, Mar 06, 2019 at 05:52:10PM +, Wei Liu wrote:
> > CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
> > 6 ships 2.6.
> >
> > Bump the version to 2.6 in README. Now that all scripts are 3
> >
>>> On 07.03.19 at 11:55, wrote:
> On Thu, Mar 07, 2019 at 03:32:12AM -0700, Jan Beulich wrote:
>> generic.c: In function ‘print_mtrr_state’:
>> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
>> bytes may cause result to exceed
>> ‘INT_MAX’ [-Werror=format-overflow=]
On Wed, Mar 06, 2019 at 05:52:10PM +, Wei Liu wrote:
> CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
> 6 ships 2.6.
>
> Bump the version to 2.6 in README. Now that all scripts are 3
> compatible, remove the restriction on python 2 as well.
>
> Update the check in
On Wed, Mar 06, 2019 at 05:52:06PM +, Wei Liu wrote:
> Do the following:
>
> 1. Change the form of "print".
> 2. Use AC_CHECK_FUNC to avoid the need to generate library name.
> 3. Remove unused stuff.
>
> Signed-off-by: Wei Liu
Reviewed-by: Anthony PERARD
Thanks.
> ---
> I doubt the
On Thu, Mar 07, 2019 at 03:23:44AM -0700, Jan Beulich wrote:
> Several build issues (new warnings, causing the build to fail due to
> -Werror) have been found. The two changes here address the ones
> I can actually repro; there are a few more related to
> -Waddress-of-packed-member which I haven't
Thanks for the patch!
On Thu, Mar 07, 2019 at 11:56:49AM +0100, Olaf Hering wrote:
> The function domcreate_bootloader_done may branch early to
> domcreate_stream_done, in case some error occoured. Here srs->dcs will be
> NULL, which leads to a crash.
>
> It is unclear what the purpose of that
The function domcreate_bootloader_done may branch early to
domcreate_stream_done, in case some error occoured. Here srs->dcs will be
NULL, which leads to a crash.
It is unclear what the purpose of that backpointer is. Perhaps it can be
removed, and domcreate_stream_done could use CONTAINER_OF.
On Thu, Mar 07, 2019 at 03:32:12AM -0700, Jan Beulich wrote:
> generic.c: In function ‘print_mtrr_state’:
> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
> bytes may cause result to exceed
> ‘INT_MAX’ [-Werror=format-overflow=]
> 210 |printk("%s %u base
On Thu, Mar 07, 2019 at 11:46:08AM +0100, Roger Pau Monné wrote:
> On Thu, Mar 07, 2019 at 03:31:43AM -0700, Jan Beulich wrote:
> > e820.c: In function ‘clip_to_limit’:
> > .../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16,
> > -36] is out of the bounds [0, 20484] of
> >
On 07/03/2019 11:23, Jan Beulich wrote:
> Several build issues (new warnings, causing the build to fail due to
> -Werror) have been found. The two changes here address the ones
> I can actually repro; there are a few more related to
> -Waddress-of-packed-member which I haven't been able to see
>
On Thu, Mar 07, 2019 at 03:31:43AM -0700, Jan Beulich wrote:
> e820.c: In function ‘clip_to_limit’:
> .../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16,
> -36] is out of the bounds [0, 20484] of
> object ‘e820’ with type ‘struct e820map’ [-Werror=array-bounds]
>10 |
>>> On 07.03.19 at 10:11, wrote:
> Commit f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit
> PV guests") introduced a regression for booting dom0 on huge systems
> with lots of RAM (in the TB range).
>
> Reason is that on those hosts the p2m list needs to be moved early in
> the
On Wed, Mar 06, 2019 at 09:58:19PM +0100, Hans van Kranenburg wrote:
> On 3/6/19 6:52 PM, Wei Liu wrote:
> > Go through the transformations suggested by 2to3 and pick the
> > necessary ones.
> >
> > Use sys.stderr.write to avoid importing from __future__.
> >
> > Signed-off-by: Wei Liu
> > ---
While I've not observed this myself, gcc 9 (imo validly) reportedly may
complain
trace.c: In function '__trace_hypercall':
trace.c:826:19: error: taking address of packed member of 'struct '
may result in an unaligned pointer value
[-Werror=address-of-packed-member]
826 | uint32_t *a =
generic.c: In function ‘print_mtrr_state’:
generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
bytes may cause result to exceed
‘INT_MAX’ [-Werror=format-overflow=]
210 |printk("%s %u base %0*"PRIx64"000 mask %0*"PRIx64"000 %s\n",
| ^
e820.c: In function ‘clip_to_limit’:
.../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16,
-36] is out of the bounds [0, 20484] of
object ‘e820’ with type ‘struct e820map’ [-Werror=array-bounds]
10 | #define memmove(d, s, n) __builtin_memmove(d, s, n)
|
Several build issues (new warnings, causing the build to fail due to
-Werror) have been found. The two changes here address the ones
I can actually repro; there are a few more related to
-Waddress-of-packed-member which I haven't been able to see
myself, and hence for now I'm unable to sort out a
On 07/03/2019 08:42, Amit Tomer wrote:
Hi,
Not really, the DT provided by Amit is for the host. The memory node
will be rewritten by Xen for Dom0 and does not include the
reserved-memory regions so far.
Thanks for pointing that out.
Is it like we need to create "separate" reserve-memory
Commit f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit
PV guests") introduced a regression for booting dom0 on huge systems
with lots of RAM (in the TB range).
Reason is that on those hosts the p2m list needs to be moved early in
the boot process and this requires temporary page
>>> On 06.03.19 at 22:38, wrote:
> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> >>> On 05.03.19 at 23:38, wrote:
>> > @@ -600,7 +602,9 @@ static void noinline init_done(void)
>> > unregister_init_virtual_region();
>> >
>> > /* Zero the .init code and data. */
>> > -for ( va =
Hi,
> Not really, the DT provided by Amit is for the host. The memory node
> will be rewritten by Xen for Dom0 and does not include the
> reserved-memory regions so far.
>
Thanks for pointing that out.
Is it like we need to create "separate" reserve-memory
node(make_reserved-memory_node) when
On 27.11.18 17:32, Kazuhito Hagio wrote:
>> Linux marks pages that are logically offline via a page flag (map count).
>> Such pages e.g. include pages infated as part of a balloon driver or
>> pages that were not actually onlined when onlining the whole section.
>>
>> While the hypervisor usually
>>> On 06.03.19 at 22:05, wrote:
> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> >>> On 05.03.19 at 23:38, wrote:
>> > @@ -600,7 +602,9 @@ static void noinline init_done(void)
>> > unregister_init_virtual_region();
>> >
>> > /* Zero the .init code and data. */
>> > -for ( va =
>>> On 06.03.19 at 21:55, wrote:
> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> > +static inline ptrdiff_t name ## _bytediff(const type s1[],
>> > \
>> > + const struct abstract_ ## name
>> > s2[])\
>> > +{
>>> On 06.03.19 at 22:16, wrote:
> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> >>> On 05.03.19 at 23:38, wrote:
>> > Use __UINTPTR_TYPE__ to define uintptr_t. A later patch will make use of
>> > __PTRDIFF_TYPE__ to define ptrdiff_t.
>> >
>> > Signed-off-by: Stefano Stabellini
>> > Reviewed-by:
100 matches
Mail list logo
