Andrew Cooper writes:
> On 16/01/2019 12:13, Alex Bennée wrote:
>> The %lu format string is different depending on the host architecture
>> which causes builds like the debian-armhf-cross build to fail. Use the
>> correct PRi64 format string.
>>
>> Signed-off-by: Alex Bennée
>> ---
>> hw/block
On Thu, Jan 17, 2019 at 10:10:00AM +0800, Dongli Zhang wrote:
> Hi Roger,
>
> On 2019/1/16 下午10:52, Roger Pau Monné wrote:
> > On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> >> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
> >> to already wake up the k
On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
> On 16.01.19 at 10:00, wrote:
> >> --- a/docs/misc/xen-command-line.pandoc
> >> +++ b/docs/misc/xen-command-line.pandoc
> >> @@ -636,61 +636,83 @@ trace feature is only enabled in debuggi
On Wed, Jan 16, 2019 at 02:49:14PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 01:20:04PM +0100, Roger Pau Monné wrote:
> > On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > >
> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: 17 January 2019 08:21
> To: Andrew Cooper
> Cc: peter.mayd...@linaro.org; Kevin Wolf ; Stefano
> Stabellini ; open list:Block layer core bl...@nongnu.org>; qemu-de...@nongnu.org; Max Reitz ;
> Paul Durrant ;
Changed the return value of 1 to 0 so now p2m_finish_type_change returns
0 for success or <0 for error.
The “root” caller of p2m_finish_type_change() is
XEN_DMOP_map_mem_type_to_ioreq_server and this does nothing useful with
positive values.
Suggested-by: George Dunlap
Signed-off-by: Alexandru Is
On 17/01/2019 08:43, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
>> On 16/01/2019 11:52, Jan Beulich wrote:
>> On 16.01.19 at 10:00, wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -636,61 +636
On 17/01/2019 10:08, Andrew Cooper wrote:
> On 17/01/2019 08:43, Roger Pau Monné wrote:
>> On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
>>> On 16/01/2019 11:52, Jan Beulich wrote:
>>> On 16.01.19 at 10:00, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/
On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko wrote:
> > This whole issue keeps getting more and more confusing.
> Well, I don't really do DMA here, but instead the buffers in
> question are shared with other Xen domain, so effectively it
> could be thought of some sort of DMA h
On Wed, Jan 16, 2019 at 06:00:33PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 05:47:19PM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> > > HVM domains use IOMMU and device model assistance for communicating wi
On Wed 2019-01-16 15:44:21, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
[...]
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c4f0a41..ae65221 100644
flight 131976 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs. 131783
build-amd64-free
On Tue, Jan 15, 2019 at 04:41:19PM +0100, Daniel Kiper wrote:
> On Tue, Jan 15, 2019 at 03:15:28PM +0100, Simon Horman wrote:
> > On Mon, Jan 14, 2019 at 01:52:07PM -0600, Eric DeVolder wrote:
> > > These changes work in conjunction with the signature
> > > verification support for Xen I published
Hi Roger,
On 01/17/2019 04:20 PM, Roger Pau Monné wrote:
> On Thu, Jan 17, 2019 at 10:10:00AM +0800, Dongli Zhang wrote:
>> Hi Roger,
>>
>> On 2019/1/16 下午10:52, Roger Pau Monné wrote:
>>> On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
There is no need to wake up xen_blkif_sche
On Tue, Jan 15, 2019 at 04:36:29PM +0100, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, handling "pci-ins" command will fail
> if pcifront is not initialized already. Fix this by sending such command
> only after confirming that pciback/front is running.
>
> Signed-off-by
On Tue, Jan 15, 2019 at 04:36:30PM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
>
> This bug prevented starting HVM with stubdomain and PCI passt
On Fri, Jan 11, 2019 at 03:37:41PM +, Alexandru Stefan ISAILA wrote:
> This is done so hvmemul_linear_to_phys() can be called from
> hvmemul_map_linear_addr()
This can also be done with a forward declaration to reduce code churn.
But that's my personal taste anyway.
Assuming this is pure code
On Wed, Jan 16, 2019 at 10:48:52PM -0800, Christopher Clark wrote:
> On Tue, Jan 15, 2019 at 7:49 AM Roger Pau Monné wrote:
> >
> > On Tue, Jan 15, 2019 at 01:27:41AM -0800, Christopher Clark wrote:
> > > sendv operation is invoked to perform a synchronous send of buffers
> > > contained in iovs t
On Wed, Jan 16, 2019 at 09:00:50AM +, Andrew Cooper wrote:
> For development purposes, it is very convenient to boot Xen as a PVH guest,
> with an XTF PV or PVH "dom0". The edit-compile-go cycle is a matter of
> seconds, and you can reasonably insert printk() debugging in places which
> which
On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
> On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné wrote:
> >
> > On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
> > > diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
> > > index c12a50f..d2cb5
>>> On 16.01.19 at 20:58, wrote:
> On 16/01/2019 14:08, Jan Beulich wrote:
>>
>>> -and the hardware must have VT-x/SVM extensions available.
>>> +* For a PVH dom0, the hardware must have VT-x/SVM extensions
>>> available.
>>>
>>> * The `shadow` boolean is only applicable when d
>>> On 16.01.19 at 20:51, wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
> On 16.01.19 at 10:00, wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -636,61 +636,83 @@ trace feature is only enabled in debugging builds of
>>> Xen.
>>>
>>>
>>> On 17.01.19 at 08:22, wrote:
> Some details of the problem:
>
> Without the macro overrides in place (ie. using the existing
> definitions) the build fails on CHECK_argo_send_addr because this
> struct is defined with types that are themselves translated by the
> compat processing:
But that
On Fri, Jan 11, 2019 at 8:31 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
(+ Leo Yan who reported a similar issues on xen-devel)
Hi Christoph,
On 16/01/2019 18:19, Christoph Hellwig wrote:
Does this fix your problem?
Thank you for the patch. This allows me to boot Dom0 on Juno r2.
My knowledge of DMA is quite limited, so I may have missed something.
Looking at th
This will help with debugging, or if we want to manually reset/restart
things.
Signed-off-by: Ian Jackson
---
cr-try-bisect | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cr-try-bisect b/cr-try-bisect
index d613c348..a2b77b9a 100755
--- a/cr-try-bisect
+++ b/cr-try-bisect
@@
>>> On 17.01.19 at 01:41, wrote:
> I am happy to make this change and also work on your suggestion above
> about using .startof. / .sizeof. in var.S, if we agree on this approach.
But sadly we look to be quite far from agreeing on anything yet.
Jan
>>> On 17.01.19 at 01:37, wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> In any event - since intermediate variables merely hide the
>> casting from the compiler, but they don't remove the casts, the
>> solution involving casts is better imo, for incurring less overhead.
>
> This is where I
>>> On 17.01.19 at 09:57, wrote:
> While not against using physdevop if we agree that a new hypercall is
> the way to go, I would prefer a domctl because this hypercall would
> only be used by toolstack components, and thus doesn't need to be
> added to the public stable ABI available to all guest
On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
> >>> On 17.01.19 at 09:57, wrote:
> > While not against using physdevop if we agree that a new hypercall is
> > the way to go, I would prefer a domctl because this hypercall would
> > only be used by toolstack components, and thus doesn
>>> On 17.01.19 at 10:14, wrote:
> On 17/01/2019 10:08, Andrew Cooper wrote:
>> On 17/01/2019 08:43, Roger Pau Monné wrote:
>>> On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
On 16/01/2019 11:52, Jan Beulich wrote:
On 16.01.19 at 10:00, wrote:
>> --- a/docs/misc/
>>> On 17.01.19 at 12:12, wrote:
> On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
>> On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné wrote:
>> > On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
>> > > +/* Sufficient space to queue space_required bytes exists
On 17/01/2019 12:59, Jan Beulich wrote:
On 17.01.19 at 10:14, wrote:
>> On 17/01/2019 10:08, Andrew Cooper wrote:
>>> On 17/01/2019 08:43, Roger Pau Monné wrote:
On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
> On 16.0
On 17/01/2019 09:14, Juergen Gross wrote:
> On 17/01/2019 10:08, Andrew Cooper wrote:
>> On 17/01/2019 08:43, Roger Pau Monné wrote:
>>> On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
On 16/01/2019 11:52, Jan Beulich wrote:
On 16.01.19 at 10:00, wrote:
>> --- a/do
>>> On 17.01.19 at 10:06, wrote:
> Changed the return value of 1 to 0 so now p2m_finish_type_change returns
> 0 for success or <0 for error.
> The “root” caller of p2m_finish_type_change() is
> XEN_DMOP_map_mem_type_to_ioreq_server and this does nothing useful with
> positive values.
By "root" I
On 17/01/2019 11:20, Jan Beulich wrote:
On 16.01.19 at 20:51, wrote:
>> On 16/01/2019 11:52, Jan Beulich wrote:
>> On 16.01.19 at 10:00, wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -636,61 +636,83 @@ trace feature is only enabl
>>> On 17.01.19 at 12:56, wrote:
> On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
>> >>> On 17.01.19 at 09:57, wrote:
>> > While not against using physdevop if we agree that a new hypercall is
>> > the way to go, I would prefer a domctl because this hypercall would
>> > only be used
>>> On 17.01.19 at 13:15, wrote:
> On 17/01/2019 11:20, Jan Beulich wrote:
> On 16.01.19 at 20:51, wrote:
>>> On 16/01/2019 11:52, Jan Beulich wrote:
>>> On 16.01.19 at 10:00, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -636
Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
hypervisors build with grant table disabled.
Signed-off-by: Wei Liu
---
I did this when I worked on splitting PV and HVM and thought this
might be useful and it was simple enough to get done.
RFC because I can envisage some co
On Thu, Jan 17, 2019 at 05:20:18AM -0700, Jan Beulich wrote:
> >>> On 17.01.19 at 12:56, wrote:
> > On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
> >> >>> On 17.01.19 at 09:57, wrote:
> >> > While not against using physdevop if we agree that a new hypercall is
> >> > the way to go,
>>> On 17.01.19 at 13:32, wrote:
> On Thu, Jan 17, 2019 at 05:20:18AM -0700, Jan Beulich wrote:
>> >>> On 17.01.19 at 12:56, wrote:
>> > On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
>> >> >>> On 17.01.19 at 09:57, wrote:
>> >> > While not against using physdevop if we agree that
On Thu, Jan 17, 2019 at 10:21:34AM +0100, Roger Pau Monné wrote:
> OK. From an architectural PoV I think it would make more sense to copy
> the list of pci devices to the stubdom config in libxl__spawn_stub_dm,
> but I'm not that familiar with pci handling in libxl, so there might
> be a reason why
>>> On 16.01.19 at 10:00, wrote:
> This option is unique to x86 PV dom0's, but it is not sensible to have a
> catch-all which blindly maps all non-RAM regions into the IOMMU.
>
> The map-reserved option remains, and covers all the buggy firmware issues that
> I am aware of.
The final part of thi
flight 131972 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-pa
>>> On 16.01.19 at 10:00, wrote:
> @@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
> This option is enabled by default on x86 systems, and invalid on ARM
> systems.
>
> +* The `none` option is intended for development purposes only, and skips
> +certain safety checks pert
On Thu, Jan 17, 2019 at 11:43:49AM +, Julien Grall wrote:
> Looking at the change for arm64, you will always call dma-direct API. In
> previous Linux version, xen-swiotlb will call dev->archdata.dev_dma_ops (a
> copy of dev->dma_ops before setting Xen DMA ops) if not NULL. Does it mean
> we exp
flight 131973 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131973/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 131960
test-armhf-armhf-x
On Thu, Jan 17, 2019 at 06:32:01AM -0700, Jan Beulich wrote:
> >>> On 16.01.19 at 10:00, wrote:
> > This option is unique to x86 PV dom0's, but it is not sensible to have a
> > catch-all which blindly maps all non-RAM regions into the IOMMU.
> >
> > The map-reserved option remains, and covers all
Add "xl get-config" printing the .config used to build the currently
running hypervisor.
Juergen Gross (2):
xen: add interface for obtaining .config from hypervisor
tools: add new xl command get-config for getting hypervisor config
.gitignore | 2 ++
docs/man/xl.1.p
Add a sysctl interface for obtaining the .config file used to build
the hypervisor. The mechanism is inspired by the Linux kernel's one.
Signed-off-by: Juergen Gross
---
.gitignore | 2 ++
tools/flask/policy/modules/dom0.te | 2 +-
xen/common/Makefile
Add new subcommand "get-config" to xl config to print the hypervisor
.config file.
To be able to reuse already existing decompressing code in libxenguest
xc_inflate_buffer() has to be moved to libxenguest.h.
Signed-off-by: Juergen Gross
---
docs/man/xl.1.pod.in | 5 +
tools/lib
On Thu, Jan 17, 2019 at 03:57:22PM +0100, Juergen Gross wrote:
> Add new subcommand "get-config" to xl config to print the hypervisor
> .config file.
I slight prefer get-xen-config or get-hypervisor-config.
>
> To be able to reuse already existing decompressing code in libxenguest
> xc_inflate
On Thu, Jan 17, 2019 at 03:57:21PM +0100, Juergen Gross wrote:
> Add a sysctl interface for obtaining the .config file used to build
> the hypervisor. The mechanism is inspired by the Linux kernel's one.
>
> Signed-off-by: Juergen Gross
> ---
> .gitignore | 2 ++
> tool
On 17/01/2019 16:12, Wei Liu wrote:
> On Thu, Jan 17, 2019 at 03:57:21PM +0100, Juergen Gross wrote:
>> Add a sysctl interface for obtaining the .config file used to build
>> the hypervisor. The mechanism is inspired by the Linux kernel's one.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> .gitigno
On 17/01/2019 16:12, Wei Liu wrote:
> On Thu, Jan 17, 2019 at 03:57:22PM +0100, Juergen Gross wrote:
>> Add new subcommand "get-config" to xl config to print the hypervisor
>> .config file.
>
> I slight prefer get-xen-config or get-hypervisor-config.
I'd be happy with either.
Anybody else got
Hello Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 18/12/2018 21:11, Volodymyr Babchuk wrote:
>> 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 ca
On 17/01/2019 15:57, Juergen Gross wrote:
> Add "xl get-config" printing the .config used to build the currently
> running hypervisor.
BTW: I'd like to have feedback especially if someone thinks this series
should by any means be part of 4.12. If not I'll send out V2 with
bumping the sysctl interf
The output from sg-report-flight might in principle contain long
lines, although this is not expected. So we are going to want to feed
it through the new cr-fold-long-lines.
Rather than piping, we are going to keep a copy of the .report file,
like is done in mg-execute-flight. So for now, just m
These are the nicely uniform bits of this change.
This arranges that many of the places where stuff gets put into emails
has their lines wrapped.
Signed-off-by: Ian Jackson
---
cr-daily-branch| 2 +-
cri-args-hostlists | 2 +-
cri-bisect | 10 +-
mg-execute-flight | 4 ++
This is a reversible transformation which usually just introduces a \
where it splits lines.
We are going to use this to wrap the lines in our emails. SMTP has a
999-byte length limit (including a CR-LF pair). This can cause our
emails to go astray. We don't really want our messages to be q-p o
On Tue, Jan 15, 2019 at 09:20:36AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 12:41:44AM +0800, Dongli Zhang wrote:
> > The xenstore 'ring-page-order' is used globally for each blkback queue and
> > therefore should be read from xenstore only once. However, it is obtained
> > in read_p
This is the remaining place where long lines might get into emails.
Signed-off-by: Ian Jackson
---
mg-execute-flight | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mg-execute-flight b/mg-execute-flight
index 349880b0..b3cdf431 100755
--- a/mg-execute-flight
+++ b/mg-execut
On Tue, 2019-01-15 at 11:41 +, Andrew Cooper wrote:
> On 15/01/2019 11:40, Juergen Gross wrote:
> > On 15/01/2019 12:38, Andrew Cooper wrote:
> > > On 15/01/2019 11:35, Juergen Gross wrote:
> > > >
> > > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-
> > > > command-line.pan
>>> On 16.01.19 at 00:35, wrote:
> @@ -273,7 +273,8 @@ static int __init nmi_apply_alternatives(const struct
> cpu_user_regs *regs,
> /* Disable WP to allow patching read-only pages. */
> write_cr0(cr0 & ~X86_CR0_WP);
>
> -apply_alternatives(__alt_instructions, __alt_i
>>> On 16.01.19 at 00:35, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -306,20 +306,23 @@ void add_taint(unsigned int flag)
> tainted |= flag;
> }
>
> -extern const initcall_t __initcall_start[], __presmp_initcall_end[],
> -__initcall_end[];
> +extern uintptr_t i
On 14/09/2017 13:58, Dario Faggioli wrote:
On Thu, 2017-09-14 at 08:42 +0200, Juergen Gross wrote:
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1077,17 +1077,21 @@ typedef struct xc_cpupoolinfo {
#define XC_CPUPOOL_POOLID_ANY 0x
+typedef xen_sysctl
>>> On 16.01.19 at 00:35, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/x86_64/var.S
> @@ -0,0 +1,92 @@
> +GLOBAL(start_)
> + .quad _start
First of all I think it would be better if there was an abstracting macro
requiring exactly one line per symbol.
Next I don't think you want these symbols to
On 17/01/2019 17:10, anshul wrote:
>
> On 14/09/2017 13:58, Dario Faggioli wrote:
>> On Thu, 2017-09-14 at 08:42 +0200, Juergen Gross wrote:
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1077,17 +1077,21 @@ typedef struct xc_cpupoolinfo {
#defi
>>> On 16.01.19 at 00:35, wrote:
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -187,8 +187,8 @@ static int __apply_alternatives_multi_stop(void *unused)
> {
> int ret;
> struct alt_region region;
> -mfn_t xen_mfn = virt_to_mfn(_start);
>
In case of soft reset the gnttab limit setting will fail, so omit it.
Setting of max vcpu count is pointless in this case, too, so we can
drop that as well.
Without this patch soft reset will fail with:
libxl: error: libxl_dom.c:363:libxl__build_pre: Couldn't set grant table limits
Reported-by:
On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > v5: Actually try to sort them, and while at it, sort all the ones I
> > touch.
>
> Applied this variant on top of drm-misc and did a build test.
> Looked good for ia64, x86 and alpha.
>
> Took a closer look at the c
Juergen Gross writes ("Re: [PATCH 2/2] tools: add new xl command get-config for
getting hypervisor config"):
> On 17/01/2019 16:12, Wei Liu wrote:
> > On Thu, Jan 17, 2019 at 03:57:22PM +0100, Juergen Gross wrote:
> >> Add new subcommand "get-config" to xl config to print the hypervisor
> >> .co
Xen-swiotlb hooks into the arm/arm64 arch code through a copy of the
DMA mapping operations stored in the struct device arch data.
Switching arm64 to use the direct calls for the merged DMA direct /
swiotlb code broke this scheme. Replace the indirect calls with
direct-calls in xen-swiotlb as wel
On Thu, 17 Jan 2019, Wei Liu wrote:
> Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> hypervisors build with grant table disabled.
Looks like a good idea.
> Signed-off-by: Wei Liu
> ---
> I did this when I worked on splitting PV and HVM and thought this
> might be useful
On Thu, Jan 17, 2019 at 09:36:57AM -0800, Stefano Stabellini wrote:
> On Thu, 17 Jan 2019, Wei Liu wrote:
> > Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> > hypervisors build with grant table disabled.
>
> Looks like a good idea.
>
>
> > Signed-off-by: Wei Liu
> > ---
On Thu, 17 Jan 2019, Wei Liu wrote:
> On Thu, Jan 17, 2019 at 09:36:57AM -0800, Stefano Stabellini wrote:
> > On Thu, 17 Jan 2019, Wei Liu wrote:
> > > Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> > > hypervisors build with grant table disabled.
> >
> > Looks like a good
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > > v5: Actually try to sort them, and while at it, sort all the ones I
> > > touch.
> >
> > Applied this variant on top of drm-misc and did a build
flight 131974 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
131957
test-amd64-i
Hi Volodymyr,
On 17/01/2019 15:21, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
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 ca
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
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, be
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
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 s
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 17/01/2019 15:21, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
The main way to communicate with OP-TEE is to issue standar
Hello Julien,
Julien Grall writes:
[...]
>> Because mediator can't share one static SHM region with all guests,
>> it just disables it for all.
>
> I haven't seen an answer to my question on the previous version. For reminder:
I'm sorry, I missed this somehow.
> Would it make sense to still al
flight 131983 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131983/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
test-amd64-i386-xl-qemu
Julien Grall writes:
> Hi Volodymyr,
>
> On 18/12/2018 21:11, Volodymyr Babchuk wrote:
>> 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
On 1/17/19 7:13 PM, Volodymyr Babchuk wrote:
Actually, OP-TEE protocol have possibility to handle limited number of
threads correctly. OP-TEE can report that all threads are busy and
client will wait for a free one. XEN can do the same, although this is not
implemented in this patch series. But
Hi,
On 1/17/19 7:22 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
[...]
Because mediator can't share one static SHM region with all guests,
it just disables it for all.
I haven't seen an answer to my question on the previous version. For reminder:
I'm sorry, I missed this somehow.
Wo
HI,
On 1/17/19 7:48 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
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
Hi,
Julien Grall writes:
> Hi,
>
> On 1/17/19 7:22 PM, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>> [...]
Because mediator can't share one static SHM region with all guests,
it just disables it for all.
>>>
>>> I haven't seen an answer to my question on the previous version.
Julien Grall writes:
> On 1/17/19 7:13 PM, Volodymyr Babchuk wrote:
Actually, OP-TEE protocol have possibility to handle limited number of
threads correctly. OP-TEE can report that all threads are busy and
client will wait for a free one. XEN can do the same, although this is not
>
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://g
On 17/01/2019 12:30, Wei Liu wrote:
> Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> hypervisors build with grant table disabled.
>
> Signed-off-by: Wei Liu
> ---
> I did this when I worked on splitting PV and HVM and thought this
> might be useful and it was simple enough
On 17/01/2019 15:23, Juergen Gross wrote:
> On 17/01/2019 15:57, Juergen Gross wrote:
>> Add "xl get-config" printing the .config used to build the currently
>> running hypervisor.
> BTW: I'd like to have feedback especially if someone thinks this series
> should by any means be part of 4.12. If no
flight 131978 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131978/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131857
test-armhf-armhf-libvirt-raw 13 saveresto
Hi,
Julien Grall writes:
> HI,
>
> On 1/17/19 7:48 PM, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
[...]
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.
flight 132022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132022/
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 1
On Thu, Jan 17, 2019 at 3:12 AM Roger Pau Monné wrote:
>
> On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
> > On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
> > > > diff --git a/xen/inc
flight 131980 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 131842
build-i386
flight 131977 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131977/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken in 131948
test-amd64-i386-xl-xsm
On Thu, 17 Jan 2019, Jan Beulich wrote:
> >>> On 17.01.19 at 01:37, wrote:
> > On Wed, 16 Jan 2019, Jan Beulich wrote:
> >> In any event - since intermediate variables merely hide the
> >> casting from the compiler, but they don't remove the casts, the
> >> solution involving casts is better imo,
1 - 100 of 105 matches
Mail list logo
