rotect dom_cow with "#ifdef CONFIG_HAS_MEM_SHARING"?
+#ifndef CONFIG_HAS_MEM_SHARING
+# define dom_cow NULL
+#endif
enum XENSHARE_flags {
SHARE_rw,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
r overall.
I am all for avoiding cluttering but not at the expense of making the
code less intuitive. In this case, I would prefer the decleration
dom_cow to be guarded.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@l
#include
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
instance of a #define overriding a prior declaration. Doing so
utilizes one of the very basic C preprocessor principles.
You are the first one usually to say that some choices in Xen were not
correct and therefore no more instance should be added.
This is one case where the resulting code is counter
notifier chain
- *
- * Removes a notifier from a raw notifier chain.
- * All locking must be provided by the caller.
- */
-void __init notifier_chain_unregister(
-struct notifier_head *nh, struct notifier_block *n)
-{
-list_del(&n->chain);
-
es?
No it was a more generic statement on the stance "It already exists in
Xen so it is fine to spread them a bit more".
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
refcnt;
};
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
line
{
...
}
/* Receive notification of CPU hotplug events. */
void register_cpu_notifier(struct notifier_block *nb);
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mai
prefer if
I was allowed to get away with this, unless a majority supports
your view. IOW - your change request is, as per my own
perspective, making the code less easy to read, even if not by
much.
Let will wait the opinion from the others here.
Cheers,
--
Julien Grall
__
is is not present in all relevant stable branches.
We currently have no Qualcomm hardware in the Xen Project test lab so
we do not need this enabled.
CC: Julien Grall
CC: linux-arm-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Stephen Boyd
CC: Andy Gross
CC: Bjorn Andersson
CC: Ava
Hi Andrii,
On 30/05/2019 17:12, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
It would have been nice to at least fix up the commit message with the typoes
(and rewording) I mentioned in my previous e-mail.
Your commit message needs to explained why this is fine to keep the
Hi,
On 30/05/2019 17:14, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
BTW, do you hear about plans for the new vgic? Some time ago it was said that
new vgic implementation going to replace the old one, and optimizing the old
is worthless. But as I see, there are no updates
Hi Andrew,
On 17/05/2019 19:58, Andrew Cooper wrote:
Reflow the ZynqMP message for grepability, and fix the omission of a newline.
Signed-off-by: Andrew Cooper
Regardless Jan's comment:
Reviewed-by: Julien Grall
I will let Jan/You to commit the patch.
Cheers,
---
CC: Jan Beulic
On 31/05/2019 18:25, Andre Przywara wrote:
On Tue, 28 May 2019 18:07:19 +0100
Julien Grall wrote:
[ ... ]
While looking at the code, I noticed that in the new vgic vgic_get_irq()
looks unsafe to be called with interrupt unmasked. This is because one
of the callee (vgic_get_lpi()) takes a
2 },
[6] = { 0 }, /* Invalid */
--
1.8.3.1
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi,
On 5/31/19 6:27 PM, Stefano Stabellini wrote:
On Fri, 31 May 2019, Julien Grall wrote:
Hi Jan,
On 31/05/2019 11:46, Jan Beulich wrote:
On 31.05.19 at 12:34, wrote:
No it was a more generic statement on the stance "It already exists in
Xen so it is fine to spread them a bit more&q
ee/optee_smc.h
create mode 100644 xen/include/asm-arm/tee/tee.h
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
"static_partitioning" that enables vwfi=native, sched=null, and also
sets debug_registers_trap and perf_counters_trap to false.
Signed-off-by: Stefano Stabellini
CC: Julien Grall
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC:
On 6/1/19 5:07 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi Volodymyr,
I tried to apply the patches to staging but fail because the patches
contains =20. Do you have a tree with the series applied?
Sure, you can find them at [1]
Thank you! The branch
, gic_set_activate_state() is
now restricted to interrupts routed to guest.
This means the _IRQ_PENDING logic is now unecessary on Arm as a same
interrupt can never come up while in the loop and nobody should play
with the flag behind our back.
Signed-off-by: Julien Grall
---
Changes in v2
Hi Artem,
On 5/22/19 7:05 PM, Artem Mygaiev wrote:
On Wed, 2019-05-22 at 14:00 +0100, Julien Grall wrote:
On 22/05/2019 13:29, Jan Beulich wrote:
On 22.05.19 at 14:20, <
julien.gr...@arm.com
wrote:
On 21/05/2019 10:55, Julien Grall wrote:
Hi Jan,
On 5/21/19 10:43 AM, Jan Beulich wr
Hi,
On 03/06/2019 02:48, chenbaodong wrote:
On 5/31/19 18:52, Julien Grall wrote:
Hi,
On 5/31/19 4:18 AM, Baodong Chen wrote:
Thus, sizeof(struct cpupool) will save 8 bytes for 64-bit system.
I am happy with the change, although AFAIK cpupool is not instantiated that
often. Are you
Hi,
On 03/06/2019 02:52, chenbaodong wrote:
On 5/31/19 18:55, Julien Grall wrote:
Hi,
On 5/31/19 3:46 AM, Baodong Chen wrote:
Signed-off-by: Baodong Chen
---
xen/common/cpu.c | 10 --
xen/include/xen/cpu.h | 4 ++--
2 files changed, 2 insertions(+), 12 deletions(-)
diff
Hi,
On 03/06/2019 11:22, chenbaodong wrote:
On 6/3/19 17:37, Julien Grall wrote:
Hi,
On 03/06/2019 02:52, chenbaodong wrote:
On 5/31/19 18:55, Julien Grall wrote:
Hi,
On 5/31/19 3:46 AM, Baodong Chen wrote:
Signed-off-by: Baodong Chen
---
xen/common/cpu.c | 10 --
xen
s can be done in follow-up:
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
(vcpu_guest_context_t);
#define XEN_DOMCTL_CONFIG_GIC_NATIVE0
#define XEN_DOMCTL_CONFIG_GIC_V21
#define XEN_DOMCTL_CONFIG_GIC_V32
I forgot to mention the newline here. This would help to differentiate the two
set of define.
I can add this one on commit.
Cheers,
--
Julien Grall
files were taken from linux tree (drivers/tee/optee/) and mangled
a bit to compile with XEN.
Can you mention the version of the Linux tree you use? This would help to track
change in the future.
With that:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
ring OP-TEE security supported".
With that:
Acked-by: Julien Grall
+ */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
calls.
Earlier, we just passed address of this buffer to OP-TEE, but
now we need to read and write to it, so it should be shadowed.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel
as Xen's PAGE_SIZE.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
yet.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Gral
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
hen issues special call
OPTEE_SMC_CALL_RETURN_FROM_RPC to resume handling of the original call.
Thus, mediator needs to maintain context for original standard call
during multiple SMCCC calls.
Standard call is considered complete, when returned value is
not a RPC request.
Signed-off-by: Volodymyr Babchuk
destroy client context. They can't block in OP-TEE, as they are
considered "fast calls" in terms of ARM SMCCC.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists
lised (PV) Guest Specific Options
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
my e-mail [1] sent 14 days ago.
Cheers,
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01771.html
Jan
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
nks,
Lukas
[1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
--
Julien Grall
No functional changes.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
Acked-by: Stefano Stabellini
Reviewed-by: George Dunlap
---
Changes in v3:
- Add George's reviewed-by
Changes in v2:
- Add Jan's reviewed-by
- Add Stefano's acked-by
--
some of the callers to use typesafe GFN and
format the message correctly.
No functional changes.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
--
Changes in v3:
- The hunk in x86/mm.c is not necessary anymore
- Update printk message to use GFN rather than frame when
This patch rework all the arch specific macros in grant_table.h to use
the typesafe MFN/GFN.
At the same time, some functions are renamed s/gmfn/gfn/ to match the
current naming scheme (see include/mm.h).
No functional changes intended.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
On x86, mfn_to_gmfn can be replaced with mfn_to_gfn. On Arm, there are
no more call to mfn_to_gmfn, so the helper can be dropped.
At the same time rework a comment in Arm code that does not make sense.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
No functional changes intended.
Signed-off-by: Julien Grall
---
Changes in v3:
- Remove gfn_x(...) for gfn used in parameter of __trace_var(...).
Changes in v2:
- Patch added
---
xen/arch/x86/mm/p2m.c | 2 +-
xen/arch/x86/mm/shadow/common.c | 31
looking at the code, I also continued to convert some code to use
typesafe MFN/GFN.
Cheers,
Julien Grall (14):
xen/x86: Make mfn_to_gfn typesafe
xen/x86: Use mfn_to_gfn rather than mfn_to_gmfn
xen/grant-table: Make arch specific macros typesafe
xen: Convert hotplug page function to use
The third parameter of update_intpte() is a MFN, so it can be switched
to use the typesafe.
At the same time, the typesafe is propagated as far as possible without
major modifications.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
---
Changes in v3:
- Remove stray change in
ninfo: A new helper is introduced to wrap the call to
mfn_to_gfn/mfn_to_gmfn. For Arm, a fixed value will be provided that will
fail on mapping if used.
[1] https://patchwork.kernel.org/patch/9719913/
Signed-off-by Julien Grall
---
Cc: oleksandr_tyshche...@epam.com
Cc: andrii_ani...@epa
No functional changes.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
Acked-by: Stefano Stabellini
Reviewed-by: George Dunlap
---
Changes in v3:
- Add George's reviewed-by
Changes in v2:
- Fix coding style
- Merge the declaration for gpfn and old
At the moment, Arm is providing a dummy implementation for the M2P
helpers used in common code. However, they are quite isolated and could
be used by other architecture in the future. So move all the helpers in
xen/mm.h.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Acked-by
function, the extern
variable dom_cow should be defined earlier on. For convenience, the
definition of all dom_* variables are moved earlier on.
Signed-off-by: Julien Grall
---
Changes in v3:
- Add missing blank
- Fix condition
Changes in v2:
- Patch added
---
xen
have not been converted to use typesafe PFN because it was requiring
more changes than expected.
Signed-off-by: Julien Grall
Acked-by: Tamas K Lengyel
Acked-by: Stefano Stabellini
---
Changes in v3:
- Add Tamas's acked-by for mem_sharing bits
- Add Stefano'
-off-by: Julien Grall
Acked-by: Jan Beulich
---
Changes in v3:
- Mention in the commit message that the typesafe is propagated
Changes in v2:
- Update error message
- Add Jan's acked-by
---
xen/arch/x86/cpu/mcheck/mcaction.c | 18 ++
xen/c
One of the printk format in audit_p2m() may be difficult to read as it
is not clear what is the first number.
Furthermore, the format can now take advantage of %pd.
Signed-off-by: Julien Grall
---
Changes in v3:
- Patch added
---
xen/arch/x86/mm/p2m.c | 3 +--
1 file changed, 1
p2m_pt_audit_p2m() has one place where the same message may be printed
twice via printk and P2M_PRINTK.
Remove the one printed using printk to stay consistent with the rest of
the code.
Take the opportunity to reflow the format of P2M_PRINTK.
Signed-off-by: Julien Grall
---
Changes in v3
There are a few places in include/public/arch-arm.h that are still
suffixing immediate with ULL instead of using xen_mk_ullong.
The latter allows a consumer to easily tweak the header if ULL is not
supported.
So switch the remaining users of ULL to xen_mk_ullong.
Signed-off-by: Julien Grall
some headache by only declaring the structure for Xen and tools.
Suggested-by: Andrew Cooper
Signed-off-by: Julien Grall
---
This is a follow-up of the discussion [1].
As this is now Xen and tools only, I am wondering whether the check on
GNU_C is still necessary. I am happy to send a
Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: George Dunlap
v4: add ASSERT_UNREACHABLE to inlined functions where applicable & other
fixups
---
xen/arch/x86/Kconfig | 6 +-
xen/arch
ers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
s the first MAX_ORDER bit of the addresses.
+ */
u64 __init pdx_init_mask(u64 base_addr)
{
-return fill_mask(base_addr - 1);
+return fill_mask(max(base_addr, (u64)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
See my comment on v2 regarding u64 vs uint64_t.
Cheers,
--
J
suggestion. Did I miss
some further part of the discussion?
No I have sent the wrong version. Not sure how because the changes are
correct in the branch I am using.
Sorry for the inconvenience, I will resend the patch.
Cheers,
--
Julien Grall
___
Xen
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52:12PM +0100, Julien Grall wrote:
The same error cannot be reproduced on laxton*. Looking at the test history,
it looks like qemu-upstream-4.12-testing flight has run successfully a few
I expect that we would not see
the failure in all the Arm platformed used in osstest but Thunder-X.
It is not a nice state to be, but the task is quite important as Xen was
designed on wrong assumption. This implies to rework most of the boot
and memory management.
Cheers,
--
Juli
Hi Stefano,
On 6/4/19 12:12 AM, Stefano Stabellini wrote:
On Wed, 29 May 2019, Julien Grall wrote:
Ping, it would be good to know which bits I dropped...
On 21/05/2019 11:09, Julien Grall wrote:
Hi,
On 5/20/19 11:56 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote
h" in the macro name when the code
is now generic. How about "domain_has_pdevs"?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
t I am happy to see this in a separate patches.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
of tied together because has_arch_pdevs is
an accessor of the field.
In a way they are. But the name of the macro hasn't become
"wrong" by the change here. That renaming you ask for could
also have been done a year ago, if so wanted.
Fair enough for non
M_32
config ARM_64
def_bool y
depends on 64BIT
+ select HAS_FAST_MULTIPLY
config ARM
def_bool y
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ASSERT_UNREACHABLE();
+rc = -EOPNOTSUPP;
+#endif
+
}
Please don't add a blank line ahead of a closing brace.
ok.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
en
Hmmm yes. I can't remember why I didn't do that before.
Reviewed-by: Jan Beulich
Thank you!
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Stabellini
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
me that their last argument is
less than their middle one.
Signed-off-by: Stefano Stabellini
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52:12PM +0100, Julien Grall wrote:
The same error cannot be reproduced on laxton*. Looking
On 6/4/19 6:59 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan,
On 6/4/19 8:06 AM, Jan Beulich wrote:
On 03.06.19 at 19:15, wrote:
On Tue, May 21, 2019 at 05:52
iscussion?
I will commit it later on with another bunch of patches.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
tched.
See above my opinion on paging_mode_translate().
Cheers,
[1] https://lists.gt.net/xen/devel/411530
Jan
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.
Do you have an example of potential
then I think for consistency you
should also touch the 3rd one (between the two).
I will only re-flow this message.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan
e to name the function parameter mfn_, and the local variable mfn.
That'll also reduce the number of uses of the unfortunate trailing-
underscore-name.
Jan
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
t enough to use MUL without us telling it to.
unsigned int test_hweight64(uint64_t t)
{
return hweight64(t);
}
I looked at the difference between before and after this patch. Before the
multiplication is not used. After, it was used with less instructions emitt
implement SHARED_M2P this way.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ch" = xen-4.11-testing ]; then
livepatch_runvars='enable_livepatch=true'
fi
eval "
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Xen.
We will just have to live with it and address them as they come in stable
branches.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Ian,
On 05/06/2019 12:31, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 2/2] RFC: enable CONFIG_LIVEPATCH in all
relevant arm64 builds"):
On 05/06/2019 12:13, Ian Jackson wrote:
Switching on CONFIG_LIVEPATCH for the affected tests will, hopefully,
make this proble
documentation patch
is going to be sent.
You can consider this as an acked:
Acked-by: Julien Grall for the two patches.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen
Hi,
On 20/05/2019 23:38, Julien Grall wrote:
On 20/05/2019 22:26, Stefano Stabellini wrote:
On Sat, 11 May 2019, Julien Grall wrote:
This is not about privilege over the system: whoever will make the
decision to ask the hypervisor to map the page will have all the
necessary rights to do it
Hi,
On 17/04/2019 22:22, Julien Grall wrote:
On 4/17/19 9:52 PM, Stefano Stabellini wrote:
Gentle ping.
As I said in [1], I don't plan to review v2 because I answered to some of the
issues in v1. You have enough to respin this.
Bumping this. On IRC you mention you have no way fo
Hi Stefano,
On 6/5/19 9:29 PM, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
No, this
d to post-boot crashes as
soon as the list would actually get traversed.
Take the opportunity and
- convert BUG_ON()s being moved to panic(),
- add __read_mostly annotations to the dom_* definitions.
Signed-off-by: Jan Beulich
For Arm:
Acked-by: Ju
Hi Jan,
On 04/06/2019 13:44, Jan Beulich wrote:
A couple of adjustments are needed to code checking for dom_cow, but
since there are pretty few it is probably better to adjust those than
to set up and keep around a never used domain.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
's opinion here.
But take this with care - I have way too little insight to have a
meaningful opinion.
Jan
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
27;t tend to mix clean-up and fix. It would be preferable if
the switch to uint64_t is done in a separate patch.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 6/5/19 10:24 AM, Julien Grall wrote:
I will commit it later on with another bunch of patches.
Pushed now.
Thank you,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen
pushed the 2 patches...
xen/arm: fix mask calculation in pdx_init_mask
... this one require input from you.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen
Hi Volodymyr,
On 6/4/19 2:31 PM, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
On 6/1/19 5:07 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi Volodymyr,
I tried to apply the patches to staging but fail because the patches
contains =20. Do
On 6/3/19 8:13 AM, Vishnu Pajjuri OS wrote:
Hi Julien Grall,
Hi,
Sorry for the late reply.
It is a pleasure for your review on Xen patch.
And Thanks for your commit suggestion and we completely agree with your
commit suggestion.
Thank you for the confirmation, I have now merged the
selected. It would also be ideal (but not mandatory)
if you can check that it does not break on non-OPTEE platform when
!CONFIG_TEE is selected.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
some headache by only declaring the structure for Xen and tools.
Suggested-by: Andrew Cooper
Signed-off-by: Julien Grall
---
This is a follow-up of the discussion [1].
[1] <3c245c5b-51c6-1d0e-ad6c-424145731...@arm.com>
Changes in v3:
- Avoid introduce a new #ifdef
Hi Stefano,
Gentle ping, you have acked the other patches but not this patch. I can't merge
them without this one.
Cheers,
On 21/05/2019 11:01, Andrii Anisov wrote:
On 14.05.19 15:24, Julien Grall wrote:
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: J
Hi Stefano,
On 05/06/2019 00:12, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be
Hi Stefano,
On 05/06/2019 00:12, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:59 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This
601 - 700 of 11146 matches
Mail list logo
