On Mon, Jun 03, 2019 at 03:10:55PM +0200, Juergen Gross wrote:
> On 03/06/2019 14:02, Ben Hutchings wrote:
> > On Mon, 2019-06-03 at 10:00 +0200, Greg KH wrote:
> >> On Thu, May 30, 2019 at 07:02:34PM -0700, Konrad Rzeszutek Wilk wrote:
> >>> On 5/30/19 8:16 AM, Ben Hutchings wrote:
> I'm
flight 137177 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137177/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 371e7001e8d5753365f3b6cd05b17e32be62b4f3
baseline version:
ovmf
flight 137173 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137173/
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. 136967
Tests which are
flight 137209 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137209/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 136901
Tests which did
On 6/3/19 22:31, Jan Beulich wrote:
On 03.06.19 at 16:08, wrote:
On Jun 3, 2019, at 11:54 AM, Jan Beulich wrote:
On 03.06.19 at 12:41, wrote:
On 6/3/19 16:31, Jan Beulich wrote:
On 03.06.19 at 05:07, wrote:
On 5/31/19 19:10, Jan Beulich wrote:
On 30.05.19 at 12:17, wrote:
Default:
Xen internal running status(trace event) will be saved to
trace memory when enabled. trace event data and config params can be
read/changed by system control hypercall at run time.
Can be disabled for smaller code footprint.
Signed-off-by: Baodong Chen
---
xen/common/Kconfig | 12
On Tue, 14 May 2019, Julien Grall wrote:
> We have multiple static page-tables defined in arch/arm/mm.c. The
> current way to define them is difficult to read and does not help when
> making modification.
>
> Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
>
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 CPU0 domheap is unnecessary.
>
> Furthermore, CPU0 page-tables are part of Xen
On 6/3/19 2:25 PM, Stefano Stabellini wrote:
> On Tue, 28 May 2019, Boris Ostrovsky wrote:
>> On 5/28/19 6:48 PM, Stefano Stabellini wrote:
>>> From: Stefano Stabellini
>>>
>>> On arm64 swiotlb is often (not always) already initialized by mem_init.
>>> We don't want to initialize it twice, which
On Tue, 14 May 2019, Julien Grall wrote:
> The boot code is using r2 and r3 to hold the page-table entry value.
> While r2 is always updated before storing the value, this is not always
> the case for r3.
>
> Thankfully today, r3 will always be zero when we care. But this is
> difficult to track
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:
> > > > The current value of HSCTLR_BASE
On Tue, 14 May 2019, Julien Grall wrote:
> The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
> are no need to initialize them during Xen boot.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2
>
On Tue, 14 May 2019, Julien Grall wrote:
> There are no reason to consider the HW CPU ID will be 0 when the
> processor is part of a uniprocessor system. At best, this will result to
> conflicting output as the rest of Xen use the value directly read from
> MPIDR.
>
> So remove the zeroing and
On Mon, Jun 3, 2019 at 4:22 PM Tamas K Lengyel wrote:
>
> > > /* XEN_DOMCTL_mem_sharing_op.
> > > - * The CONTROL sub-domctl is used for bringup/teardown. */
> > > + * The CONTROL sub-domctl is used for bringup/teardown.
> > > + * Please note that mem sharing can be turned on *without*
> > /* XEN_DOMCTL_mem_sharing_op.
> > - * The CONTROL sub-domctl is used for bringup/teardown. */
> > + * The CONTROL sub-domctl is used for bringup/teardown.
> > + * Please note that mem sharing can be turned on *without* setting-up the
> > + * correspondin ring
> > + */
>
> As a tangent, it
Hi,
On 6/3/19 11:02 PM, Stefano Stabellini wrote:
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index bb7e437049..a3c6f4c1ee 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -50,9 +50,12 @@ static u64 __init fill_mask(u64 mask)
return mask;
}
+/*
+ * We don't compress the
pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by bdb5439c3f ("x86_64: Ensure frame-table
compression leaves MAX_ORDER aligned"), when changing to loop to start
from MAX_ORDER-1 an adjustment by
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0x
which is the biggest possible mask and ends up causing a significant
memory waste in the
Hi Stefano,
On 6/3/19 10:56 PM, Stefano Stabellini wrote:
On Thu, 9 May 2019, Jan Beulich wrote:
On 09.05.19 at 00:47, wrote:
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -50,9 +50,13 @@ static u64 __init fill_mask(u64 mask)
return mask;
}
+/*
+ * We always map the first 1<
Hi all,
This series is a small collection of PDX fixes. They are technically
independent but discovered together trying to understand the memory
waste caused by the frametable allocation on Xilinx ZynqMP.
Cheers,
Stefano
The following changes since commit
flight 137171 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137171/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail in 137112 pass in
On Thu, 9 May 2019, Jan Beulich wrote:
> >>> On 09.05.19 at 00:47, wrote:
> > --- a/xen/common/pdx.c
> > +++ b/xen/common/pdx.c
> > @@ -50,9 +50,13 @@ static u64 __init fill_mask(u64 mask)
> > return mask;
> > }
> >
> > +/*
> > + * We always map the first 1< > + * are left uncompressed.
>
Fedora rawhide is about to to update to Python 3.8 (in beta I think) and
there are two issues with compiling xen with it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1704807 ).
It seems that in 3.8 python3-config --libs no longer includes -lpython3.8
by default which causes tools/configure
flight 137263 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137263/
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
On Mon, Jun 3, 2019 at 2:25 AM Jan Beulich wrote:
>
> >>> On 02.06.19 at 02:40, wrote:
> > On Fri, May 31, 2019 at 3:35 AM 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
flight 137169 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137169/
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
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
> times on rochester*. So we may have fixed the error in Xen 4.12.
>
>
flight 137250 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137250/
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
On Mon, Jun 3, 2019 at 10:40 AM Julien Grall wrote:
>
> Hi,
>
> On 03/06/2019 17:38, Tamas K Lengyel wrote:
> > On Mon, Jun 3, 2019 at 2:26 AM Jan Beulich wrote:
> >>
> > On 16.05.19 at 23:37, wrote:
> >>> Disable it by default as it is only an experimental subsystem.
> >>>
> >>>
Hi,
On 03/06/2019 17:38, Tamas K Lengyel wrote:
On Mon, Jun 3, 2019 at 2:26 AM Jan Beulich wrote:
On 16.05.19 at 23:37, wrote:
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau
On Mon, Jun 3, 2019 at 2:26 AM Jan Beulich wrote:
>
> >>> On 16.05.19 at 23:37, wrote:
> > Disable it by default as it is only an experimental subsystem.
> >
> > Signed-off-by: Tamas K Lengyel
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > Cc: Wei Liu
> > Cc: Roger Pau Monne
> > Cc: George
On Mon, Jun 03, 2019 at 09:40:19AM -0600, Jan Beulich wrote:
> >>> On 03.06.19 at 16:12, wrote:
> > On Wed, May 29, 2019 at 04:17:49AM -0600, Jan Beulich wrote:
> >> In particular with an enabled IOMMU (but not really limited to this
> >> case), trying to invoke fixup_irqs() after having already
flight 137158 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed by the tools and Xen. It is also
not expected to be ever used outside of that context. So we could save us
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
The first parameter of {s,g}et_gpfn_from_mfn() is an MFN, so it can be
switched to use the typesafe.
At the same time, replace gpfn with pfn in the helpers as they all deal
with PFN and also turn the macros to static inline.
Note that the return of the getter and the 2nd parameter of the setter
Convert online_page, offline_page and query_page_offline to use
typesafe MFN.
At the same time, the typesafe is propagated as far as possible without
major modifications.
Note, for clarity, the words have been re-ordered in the error message
updated by this patch.
No functional changes.
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:
set_gpfn_from_mfn() is currently implement in a 2 part macros. The
second macro is only called within the first macro, so they can be
folded together.
Furthermore, this is now converted to a static inline making the code
more readable and safer.
As set_gpfn_from_mfn is now a static inline
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
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
Hi all,
Arm never supported a M2P yet there are some helpers implemented to deal with
the common code. However, the implementation of mfn_to_gmfn is completely
bogus.
This series aims to properly disable the M2P on Arm. See patch #8 for the
rationale regarding the lack of M2P on Arm.
While
While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty
bogus as we directly return the MFN passed in parameter.
Thankfully, the use of mfn_to_gmfn is pretty limited on Arm today. There
are only 3 callers:
- iommu_hwdom_init: mfn_to_gmfn is used for creating IOMMU
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
---
mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
is using mfn_t and gfn_t (return type).
Furthermore, the naming of the former is more consistent with the
current naming scheme (GFN/MFN). So replace mfn_to_gmfn with
mfn_to_gfn in x86 code.
Take the opportunity to convert
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
---
>>> On 30.05.19 at 16:18, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
> #include "hvm/save.h"
> #include "memory.h"
>
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x0011
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0012
I don't think
>>> On 03.06.19 at 16:12, wrote:
> On Wed, May 29, 2019 at 04:17:49AM -0600, Jan Beulich wrote:
>> In particular with an enabled IOMMU (but not really limited to this
>> case), trying to invoke fixup_irqs() after having already done
>> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
>>
On Fri, 2019-05-31 at 17:06 -0700, Andrew Cooper wrote:
> On 31/05/2019 16:43, Andrew Cooper wrote:
> > On 30/05/2019 07:18, Petre Pircalabu wrote:
> > > The domain reference can be part of the vm_event_domain structure
> > > because for every call to a vm_event interface function both the
> > >
On 29/05/2019 15:06, Lukas Jünger wrote:
Hi all,
Hi,
Is there a way to map a region of physical memory to dom0/domU?
Yes, you can use the option 'iomem'.
Let's say I have a custom device mapped at that memory region and I want either
dom0 or a domU to have full access to this device.
On 6/3/19 3:25 PM, Andrew Cooper wrote:
vm_event_resume() should use domain_vcpu(), rather than opencoding it
without its Spectre v1 safety.
vm_event_wake_blocked() can't ever be invoked in a case where d->vcpu is
NULL, so drop the outer if() and reindent, fixing up style issues.
The comment,
>>> On 03.06.19 at 03:57, wrote:
> Signed-off-by: Baodong Chen
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 137233 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137233/
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
Volodymyr Babchuk writes ("[Xen-devel] [PATCH v5 10/10] tools/arm: optee:
create optee firmware node in DT if tee=optee"):
> If TEE support is enabled with "tee=optee" option in xl.cfg,
> then we need to inform guest about available TEE, by creating
> corresponding node in the guest's device
Volodymyr Babchuk writes ("[Xen-devel] [PATCH v5 09/10] tools/arm: tee: add
"tee" option for xl.cfg"):
> This enumeration controls TEE type for a domain. Currently there is
> two possible options: either 'none' or 'optee'.
>
> 'none' is the default value and it basically disables TEE support at
>>> On 03.06.19 at 11:58, wrote:
> 'notifier_block' can be replaced with 'list_head' when used for
> 'notifier_head', this makes a little clearer.
>
> Signed-off-by: Baodong Chen
Acked-by: Jan Beulich
___
Xen-devel mailing list
On 6/3/19 3:25 PM, Andrew Cooper wrote:
The use of (*ved)-> leads to poor code generation, as the compiler can't
assume the pointer hasn't changed, and results in hard-to-follow code.
For both vm_event_{en,dis}able(), rename the ved parameter to p_ved, and
work primarily with a local ved
>>> On 03.06.19 at 16:08, wrote:
>
>> On Jun 3, 2019, at 11:54 AM, Jan Beulich wrote:
>>
> On 03.06.19 at 12:41, wrote:
>>
>>> On 6/3/19 16:31, Jan Beulich wrote:
>>> On 03.06.19 at 05:07, wrote:
> On 5/31/19 19:10, Jan Beulich wrote:
> On 30.05.19 at 12:17, wrote:
On 6/3/19 3:25 PM, Andrew Cooper wrote:
* Drop redundant brackes, and inline qualifiers.
* Insert newlines and spaces where appropriate.
* Drop redundant NDEBUG - gdprint() is already conditional. Fix the
logging level, as gdprintk() already prefixes the guest marker.
No functional
On Wed, May 29, 2019 at 04:17:49AM -0600, Jan Beulich wrote:
> In particular with an enabled IOMMU (but not really limited to this
> case), trying to invoke fixup_irqs() after having already done
> disable_IO_APIC() -> clear_IO_APIC() is a rather bad idea:
>
> RIP:e008:[]
This is a note to let you know that I've just added the patch titled
x86: xen: no need to check return value of debugfs_create functions
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing
On Fri, 2019-05-31 at 17:25 -0700, Andrew Cooper wrote:
> On 30/05/2019 07:18, Petre Pircalabu wrote:
> > This patchset adds a new mechanism of sending synchronous vm_event
> > requests and handling vm_event responses without using a ring.
> > As each synchronous request pauses the vcpu until the
On 6/3/19 3:25 PM, Andrew Cooper wrote:
These serve no purpose, but to add to the congnitive load of following
the code. Remove the level of indirection.
Furthermore, the lock protects all data in vm_event_domain, making
ring_lock a poor choice of name.
For vm_event_get_response() and
On 6/3/19 3:25 PM, Andrew Cooper wrote:
This parameter isn't used at all. Futhermore, elide the copyback in
failing cases, as it is only successful paths which generate data which
needs sending back to the caller.
Finally, drop a redundant d == NULL check, as that logic is all common
at the
>>> On 03.06.19 at 14:25, wrote:
> This parameter isn't used at all. Futhermore, elide the copyback in
> failing cases, as it is only successful paths which generate data which
> needs sending back to the caller.
>
> Finally, drop a redundant d == NULL check, as that logic is all common
> at
Hi Jan,
On 03/06/2019 10:34, Jan Beulich wrote:
On 01.06.19 at 10:43, wrote:
flight 137100 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On 03/06/2019 14:02, Ben Hutchings wrote:
> On Mon, 2019-06-03 at 10:00 +0200, Greg KH wrote:
>> On Thu, May 30, 2019 at 07:02:34PM -0700, Konrad Rzeszutek Wilk wrote:
>>> On 5/30/19 8:16 AM, Ben Hutchings wrote:
I'm looking at CVE-2015-8553 which is fixed by:
commit
This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
was redundant with amd_iommu_detect_one_acpi() already calling
pci_ro_device().
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1021,8 +1021,6 @@
Hi Volodymyr,
Some comment on the documentation, the rest looks good to me.
On 21/05/2019 22:26, Volodymyr Babchuk wrote:
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c7d70e618b..73c64dc896 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@
> On Jun 3, 2019, at 1:33 PM, Andrew Cooper wrote:
>
> Drop the ap2m_active boolean, and consistently use the unlocking form:
>
> if ( p2m != hostp2m )
> __put_gfn(p2m, gfn);
> __put_gfn(hostp2m, gfn);
>
> which makes it clear that we always unlock the altp2m's gfn if it is in use,
>
Hi Volodymyr,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and then return an error
to all calls to the guest.
This code issues two non-preemptible calls to OP-TEE: to create and
to
Hi Volodymyr,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
This patch adds handling for the fast SMCs. As name suggests, those
calls can't be preempted and are used for auxiliary tasks such as
information retrieval. Most handlers are quite trivial, with exception
for capabilities information.
Hi Volodymyr,
On 21/05/2019 22:26, Volodymyr Babchuk wrote:
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,
Drop the ap2m_active boolean, and consistently use the unlocking form:
if ( p2m != hostp2m )
__put_gfn(p2m, gfn);
__put_gfn(hostp2m, gfn);
which makes it clear that we always unlock the altp2m's gfn if it is in use,
and always unlock the hostp2m's gfn. This also drops the ternary
Hi Volodymyr,
On 21/05/2019 22:26, Volodymyr Babchuk wrote:
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
Hi Volodymyr,
On 21/05/2019 22:26, Volodymyr Babchuk wrote:
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
Hi Volodymyr,
On 21/05/2019 22:26, Volodymyr Babchuk wrote:
+while ( pg_count )
+{
+struct page_info *page;
+
+if ( idx == 0 )
+{
+guest_pg = get_domain_ram_page(gfn);
+if ( !guest_pg )
+return -EINVAL;
+
+
These serve no purpose, but to add to the congnitive load of following
the code. Remove the level of indirection.
Furthermore, the lock protects all data in vm_event_domain, making
ring_lock a poor choice of name.
For vm_event_get_response() and vm_event_grab_slot(), fold the exit
paths to have
This came about from reviewing Petre's "Per vcpu vm_event channels" while sat
in an airport with plenty of time to kill. This started with patch 4 trying
to get rid of the "k = i % d->max_vcpus;" expression, but see patch 4 for
further details of why it has stayed.
Everything else was either
The use of (*ved)-> leads to poor code generation, as the compiler can't
assume the pointer hasn't changed, and results in hard-to-follow code.
For both vm_event_{en,dis}able(), rename the ved parameter to p_ved, and
work primarily with a local ved pointer.
This has a key advantage in
* Drop redundant brackes, and inline qualifiers.
* Insert newlines and spaces where appropriate.
* Drop redundant NDEBUG - gdprint() is already conditional. Fix the
logging level, as gdprintk() already prefixes the guest marker.
No functional change.
Signed-off-by: Andrew Cooper
---
CC:
vm_event_resume() should use domain_vcpu(), rather than opencoding it
without its Spectre v1 safety.
vm_event_wake_blocked() can't ever be invoked in a case where d->vcpu is
NULL, so drop the outer if() and reindent, fixing up style issues.
The comment, which is left alone, is false. This
flight 137143 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
On Mon, 2019-06-03 at 10:00 +0200, Greg KH wrote:
> On Thu, May 30, 2019 at 07:02:34PM -0700, Konrad Rzeszutek Wilk wrote:
> > On 5/30/19 8:16 AM, Ben Hutchings wrote:
> > > I'm looking at CVE-2015-8553 which is fixed by:
> > >
> > > commit 7681f31ec9cdacab4fd10570be924f2cef6669ba
> > > Author:
Hi,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
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
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eb424e8286..5e938a91cc 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -304,10 +304,13 @@
Hi Volodymyr,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ccb0f181ea..1a240d208b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
On Fri, 2019-05-31 at 16:44 -0700, Andrew Cooper wrote:
> On 30/05/2019 07:18, Petre Pircalabu wrote:
> > The vm_event_domain members are not accessed outside vm_event.c so
> > it's
> > better to hide de implementation details.
> >
> > Signed-off-by: Petre Pircalabu
>
> Acked-by: Andrew Cooper
On 6/3/19 18:40, Julien Grall wrote:
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
---
>>> On 03.06.19 at 12:41, wrote:
> On 6/3/19 16:31, Jan Beulich wrote:
> On 03.06.19 at 05:07, wrote:
>>> On 5/31/19 19:10, Jan Beulich wrote:
>>> On 30.05.19 at 12:17, wrote:
> Default: enabled.
> Can be disabled for smaller code footprint.
But you're aware that we're,
On 6/3/19 16:31, Jan Beulich wrote:
On 03.06.19 at 05:07, wrote:
On 5/31/19 19:10, Jan Beulich wrote:
On 30.05.19 at 12:17, wrote:
Default: enabled.
Can be disabled for smaller code footprint.
But you're aware that we're, for now at least, trying to limit the
number of independently
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 --
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/include/xen/cpu.h | 4 ++--
2 files changed,
On 6/3/19 17:30, Julien Grall wrote:
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
On 03/06/2019 11:02, Jan Beulich wrote:
On 31.05.19 at 21:40, wrote:
>> On 31/05/2019 02:51, Jan Beulich wrote:
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -153,41 +153,54 @@ static __inline__ int get_count_order(un
>>>
>>> static inline unsigned int
>>> On 31.05.19 at 21:40, wrote:
> On 31/05/2019 02:51, Jan Beulich wrote:
>> --- a/xen/include/xen/bitops.h
>> +++ b/xen/include/xen/bitops.h
>> @@ -153,41 +153,54 @@ static __inline__ int get_count_order(un
>>
>> static inline unsigned int generic_hweight32(unsigned int w)
>> {
>> -
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 May 2019 10:07
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH 5/5] iommu / pci: re-implement
> XEN_DOMCTL_get_device_group...
>
> On Wed, May 08, 2019 at 02:24:03PM +0100,
'notifier_block' can be replaced with 'list_head' when used for
'notifier_head', this makes a little clearer.
Signed-off-by: Baodong Chen
---
xen/common/notifier.c | 12 ++--
xen/include/xen/notifier.h | 7 +++
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git
1 - 100 of 119 matches
Mail list logo
