flight 33450 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33450/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 guest-start fail REGR. vs. 33112
test-amd64-i386-free
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://x
flight 33458 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 33422
build-armhf-libvirt
Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
>
> e.g. of the current issue.
> Starting
flight 33442 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
flight 33454 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33454/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen ffcd777f8062fb24dff7c9d2a46547001e158b05
baseline version:
rumpuserxen ec3b62146d52e5deab349b00c6e7
>
> I would have thought, from the tone of your earlier comments, that
> you were aiming for a bar somewhat higher than "as good as
> nestedp2m". :) I hope you'll also understand that given how well that
> has turned out, we shouldn't necessarily apply the same standard to
> new code as we did t
>
>> As I said in discussion with Andrew, my aim was to make it possible
>> for these same changes to be extensible to AMD processors if they
>> support multiple copies of whatever their EPT equivalent is, by
>> simply emulating VMFUNC and #VE. That's why there are some wrappers
>> in the implemen
Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerab
Applicants should be required to:
- Provide information on their public web pages which makes
it clear that and why they are eligible;
- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);
- Provide a way for members of t
Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html | 21 +
1 file changed, 21 insertions(+)
diff --git a/security_vulnerabilit
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
index d6e0df5..df52221 100644
--- a/security_vulnerab
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
index de5e83e..4fd02e9 100644
--- a/security_vulner
Service provider list members should not be prevented from being
reasonably honest with their users.
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html |8
1 file changed, 8 insertions(+)
diff --git a/security_vulnerability_process.html
No semantic change.
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security_vulnerability_process.html
b/security_vulnerability_process.html
index 7069646..4ed0042 100644
--- a
- For Predisclosure list application process
- For Handling of embargoed information"
No semantic change.
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
---
security_vulnerability_process.html |2 ++
1 file changed, 2 insertions(+)
diff --git a/security_vulnerability_process.html
The prior consultation clause should applies to all disclosure
exceptions. The list end appears to have been moved by mistake. So
put it back.
Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108
process post-mortem"):
> I would say, give it a week for further feedback and then prepare a patch.
It's been rather longer than a week - sorry.
I would like to propose the following series of changes to the Xen
Project Se
On 16/01/15 19:11, Iurii Konovalenko wrote:
> On Fri, Jan 16, 2015 at 6:31 PM, Julien Grall wrote:
>>
>> On 16/01/15 16:17, Iurii Konovalenko wrote:
>>> I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" :
>>> : "r" (freq));
>>> Also I tried to write it via Xen API: WRITE_SYSREG
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108
process post-mortem"):
> On 10 Nov 2014, at 18:01, Ian Jackson wrote:
...
> > The Security Team will impose deployment restrictions only insofar
> > as it is necessary to prevent the exposure of technicalities (for
> > e
On 01/16/15 02:57, Jan Beulich wrote:
On 15.01.15 at 22:00, wrote:
>> On 01/15/15 11:42, Jan Beulich wrote:
>> On 02.10.14 at 23:30, wrote:
--- /dev/null
+++ b/xen/arch/x86/hvm/vmware/cpuid.c
>>>
>>> Whether adding another subdirectory here is really the way to go
>>> heavily d
flight 33437 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
Regressions which
On Fri, Jan 16, 2015 at 6:31 PM, Julien Grall wrote:
>
> On 16/01/15 16:17, Iurii Konovalenko wrote:
> > I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" :
> > : "r" (freq));
> > Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
> >
> > But unfortunately
On 16/01/15 18:24, Dugger, Donald D wrote:
> One of our engineers, Maciek, is working on a driver and stumbled upon
> what looks like a bug in the Xen kernel. The report I got was:
>
>
>
> We recently started to provide mmap functionality in our driver for
> Linux. Function for this:
>
>
>
On 01/16/2015 09:52 AM, Tim Deegan wrote:
> At 12:38 -0800 on 15 Jan (1421321902), Ed White wrote:
>> On 01/15/2015 09:03 AM, Tim Deegan wrote:
>>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
This is treated exactly like p2m_ram_rw, except that suppress_ve is not
set in the EPT
Hi,
At 10:23 -0800 on 15 Jan (1421313824), Ed White wrote:
> On 01/15/2015 08:15 AM, Tim Deegan wrote:
> > I see there's been some discussion of how this would be useful for an
> > out-of-domain inspection tool, but could you talk some more about the
> > usefulness of the in-VM callers? I'm not s
One of our engineers, Maciek, is working on a driver and stumbled upon what
looks like a bug in the Xen kernel. The report I got was:
We recently started to provide mmap functionality in our driver for Linux.
Function for this:
int
NalMmap(
struct file*File,
On Thu, Jan 15, 2015 at 09:04:35PM +0800, Jiang Liu wrote:
> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
> setup_IO_APIC(), so no irqdomains created for IOAPICs and
> mp_map_pin_to_irq() fails at the
At 13:00 -0800 on 15 Jan (1421323248), Ed White wrote:
> On 01/15/2015 09:33 AM, Tim Deegan wrote:
> > Hi,
> >
> > Sorry for the fractured replies - my notes are confused about which
> > functions were defined where.
> >
> > At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
> >> +bool_t p2m_
At 12:57 -0800 on 15 Jan (1421323048), Ed White wrote:
> On 01/15/2015 09:25 AM, Tim Deegan wrote:
> > Hi,
> >
> > At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
> >> +int
> >> +altp2mhvm_hap_nested_page_fault(struct vcpu *v, paddr_t gpa,
> >> +unsigned long
At 12:49 -0800 on 15 Jan (1421322565), Ed White wrote:
> On 01/15/2015 09:20 AM, Tim Deegan wrote:
> > Hi,
> >
> > The locking chages look OK at first glance, but...
> >
> > At 13:26 -0800 on 09 Jan (1420806400), Ed White wrote:
> >> @@ -793,6 +793,10 @@ int p2m_change_type_one(struct domain *d,
On 01/16/2015 09:50 AM, Tim Deegan wrote:
> At 10:55 -0800 on 15 Jan (1421315724), Ed White wrote:
>> On 01/15/2015 08:56 AM, Tim Deegan wrote:
>>> Hi,
>>>
>>> At 13:26 -0800 on 09 Jan (1420806396), Ed White wrote:
@@ -2551,6 +2640,17 @@ static void vmx_vmexit_ud_intercept(struct
cpu_use
At 12:43 -0800 on 15 Jan (1421322197), Ed White wrote:
> On 01/15/2015 09:09 AM, Tim Deegan wrote:
> > Hi,
> >
> > These _definitely_ need XSM checks, otherwise any domain can call them
> > on any other! I think you can probably copy the other p2m-munging
> > operations to see how to make a sensi
At 12:38 -0800 on 15 Jan (1421321902), Ed White wrote:
> On 01/15/2015 09:03 AM, Tim Deegan wrote:
> > At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
> >> This is treated exactly like p2m_ram_rw, except that suppress_ve is not
> >> set in the EPTE.
> >
> > I don't think this is going to wo
At 10:55 -0800 on 15 Jan (1421315724), Ed White wrote:
> On 01/15/2015 08:56 AM, Tim Deegan wrote:
> > Hi,
> >
> > At 13:26 -0800 on 09 Jan (1420806396), Ed White wrote:
> >> @@ -2551,6 +2640,17 @@ static void vmx_vmexit_ud_intercept(struct
> >> cpu_user_regs *regs)
> >> hvm_inject_hw_ex
Hello,
On 16/01/15 17:33, Vitaly Kuznetsov wrote:
> Julien Grall writes:
>
>> The code to load the kernel is only used when Xen builds dom0. It
>> happens during the boot.
>
> I suppose we don't have dom0 kexec for ARM now or this code is not
> (won't be) required?
We don't have support for DO
Julien Grall writes:
> The code to load the kernel is only used when Xen builds dom0. It
> happens during the boot.
I suppose we don't have dom0 kexec for ARM now or this code is not
(won't be) required?
--
Vitaly
___
Xen-devel mailing list
Xen-de
Hi Stefano /clark,
Thanks for sharing the link. For dom0 I am using openSuse.
I have followed the steps listed on
the(https://libvirt.org/compiling.html#building) to build and install. I
believe build-librvit-deb would be doing the same steps or I need to create
libvirt-xen.spec.in ?
I need som
At 10:49 -0800 on 15 Jan (1421315382), Ed White wrote:
> On 01/15/2015 08:53 AM, Jan Beulich wrote:
> On 15.01.15 at 17:48, wrote:
> >> At 13:26 -0800 on 09 Jan (1420806395), Ed White wrote:
> >>> +/* Init alternate p2m data */
> >>> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page())
At 10:46 -0800 on 15 Jan (1421315210), Ed White wrote:
> On 01/15/2015 08:25 AM, Tim Deegan wrote:
> > Hi,
> >
> > At 13:26 -0800 on 09 Jan (1420806392), Ed White wrote:
> >> static inline bool_t is_epte_valid(ept_entry_t *e)
> >> {
> >> -return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
>
On 01/16/2015 02:43 AM, Tamas K Lengyel wrote:
> On Thu, Jan 15, 2015 at 6:31 PM, Ed White wrote:
>> On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
There are ways of avoiding the
single-step too, although I don't think that falls within the scope
of this conversation.
Ed
>
On Thu, Jan 15, 2015 at 08:09:34AM +, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: Thursday, January 15, 2015 4:43 AM
> >
> > On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@ora
On 01/16/2015 12:24 AM, Jan Beulich wrote:
On 15.01.15 at 22:00, wrote:
>> On 01/15/2015 09:33 AM, Tim Deegan wrote:
>>> Hi,
>>>
>>> Sorry for the fractured replies - my notes are confused about which
>>> functions were defined where.
>>>
>>> At 13:26 -0800 on 09 Jan (1420806398), Ed White wr
On 01/16/2015 12:20 AM, Jan Beulich wrote:
On 15.01.15 at 21:38, wrote:
>> On 01/15/2015 09:03 AM, Tim Deegan wrote:
>>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
This is treated exactly like p2m_ram_rw, except that suppress_ve is not
set in the EPTE.
>>>
>>> I don't th
On 01/16/2015 11:57 AM, Andrew Cooper wrote:
On 16/01/15 16:45, Jan Beulich wrote:
On 16.01.15 at 17:38, wrote:
On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
On 16.01.15 at 17:16, wrote:
On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
On 01/07/2
On 01/16/2015 12:12 AM, Jan Beulich wrote:
On 15.01.15 at 19:23, wrote:
>> On 01/15/2015 08:15 AM, Tim Deegan wrote:
>>> - Feature compatibilty/completeness. You pointed out yourself that
>>> it doesn't work with nested HVM or migration. I think I'd have to
>>> add mem_event/access/pagi
On 16/01/15 16:45, Jan Beulich wrote:
On 16.01.15 at 17:38, wrote:
>> On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
>> On 16.01.15 at 17:16, wrote:
On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
>> On 01/07/2015 04:12 AM, Jan
On 01/15/2015 11:35 PM, Jan Beulich wrote:
On 15.01.15 at 18:28, wrote:
>> On 01/15/2015 12:16 AM, Jan Beulich wrote:
>> On 14.01.15 at 18:35, wrote:
Right. The key observation is that at any single point in time, a given
hardware thread can be fetching an instruction or readin
>>> On 16.01.15 at 17:38, wrote:
> On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
>> >>> On 16.01.15 at 17:16, wrote:
>> > On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
>> >> >>> On 16.01.15 at 16:56, wrote:
>> >> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
>> >> > On 06.01.1
>>> On 16.01.15 at 17:34, wrote:
> On 01/16/2015 11:20 AM, Jan Beulich wrote:
> On 16.01.15 at 17:14, wrote:
>>> On 01/16/2015 11:06 AM, Jan Beulich wrote:
>>> On 16.01.15 at 16:56, wrote:
> On 01/07/2015 04:12 AM, Jan Beulich wrote:
> On 06.01.15 at 14:41, wrote:
>>> On
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2015 16:28
> To: Paul Durrant
> Cc: David Vrabel; xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: Re: [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls
>
> >>> On 16.01.15 at 11:09, wrote:
> > --- a/xe
On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
> >>> On 16.01.15 at 17:16, wrote:
> > On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >> >>> On 16.01.15 at 16:56, wrote:
> >> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> >> > On 06.01.15 at 14:41, wrote:
> >> >>> On 06/01/15
>>> On 16.01.15 at 17:16, wrote:
> On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
>> >>> On 16.01.15 at 16:56, wrote:
>> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
>> > On 06.01.15 at 14:41, wrote:
>> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
>> Instead of copying data for
On 01/16/2015 11:20 AM, Jan Beulich wrote:
On 16.01.15 at 17:14, wrote:
On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for ea
On 16/01/15 16:28, Andrew Cooper wrote:
> On 16/01/15 16:20, Julien Grall wrote:
>> add_boot_module is calling a function which lies in the init section.
>> Furthermore, it's only used during Xen boot.
>>
>> Signed-off-by: Julien Grall
>> ---
>> xen/arch/arm/setup.c| 6 +++---
>> xen/incl
On 16/01/15 16:17, Iurii Konovalenko wrote:
> I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" :
> : "r" (freq));
> Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
>
> But unfortunately Xen fails on both this instructions with "Undefined
> instruction"
On 16/01/15 16:20, Julien Grall wrote:
> add_boot_module is calling a function which lies in the init section.
> Furthermore, it's only used during Xen boot.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/setup.c| 6 +++---
> xen/include/asm-arm/setup.h | 8
> 2 files chang
>>> On 16.01.15 at 11:09, wrote:
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
> } u;
>
> struct tasklet assert_evtchn_irq_tasklet;
> +u8 evtchn_upcall_vector;
>
> struct nestedvcpu
Hi all
I`m trying to track code execution with page granularity by setting the access
rights in the EPT to not executable on Xen 4.4.1.
The idea is as follows:
According to the intel manual "A reference using a guest-physical address
whose translation encounters an EPT paging-structure that is
When CPU hotplug will be supported, it will require to bring up a CPU.
Signed-off-by: Julien Grall
---
I'm not sure if we should flag these functions with __cpuinit. The
define doesn't do anything.
---
xen/arch/arm/arm32/smpboot.c | 4 ++--
xen/arch/arm/platform.c | 2 +-
xen/arch/arm/smp
The callbacks init_time and specific_mapping are respectively used
during timer initialization and DOM0 building. These 2 taks only
happen during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/platforms/exynos5.c | 4 ++--
xen/arch/arm/platforms/omap5.c | 4 ++--
xen/arch/arm
>>> On 16.01.15 at 17:14, wrote:
> On 01/16/2015 11:06 AM, Jan Beulich wrote:
> On 16.01.15 at 16:56, wrote:
>>> On 01/07/2015 04:12 AM, Jan Beulich wrote:
>>> On 06.01.15 at 14:41, wrote:
> On 06/01/15 02:18, Boris Ostrovsky wrote:
>> Instead of copying data for each field in xe
The function is calling device_is_compatible which lies in init section
and is only called during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/device.c| 2 +-
xen/include/asm-arm/device.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/device
Hello,
This small series add/remove __init on different functions. This allow Xen to
free around 8Kb more of memory after it has finished to boot.
Xen size in memory before to free init section: 1029Kb
Freed memory init: 288Kb
Regards,
Julien Grall (6):
arm/setup: Add missing __init to add_bo
The code to load the kernel is only used when Xen builds dom0. It
happens during the boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/kernel.c | 30 +++---
xen/arch/arm/kernel.h | 4 ++--
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/ker
The code to build DOM0 is only used during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 66 ++---
xen/include/asm-arm/setup.h | 2 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b
add_boot_module is calling a function which lies in the init section.
Furthermore, it's only used during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c| 6 +++---
xen/include/asm-arm/setup.h | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/
Hi,
I'm trying to measure number of cycles for hypercalls.
I'm working on ARM v7 and v8.
Xentrace seems to be a right tool to use according to this discussion.
http://lists.xen.org/archives/html/xen-devel/2008-10/msg00480.html
However when I ran it on ARM, it gave an error.
The error is the same
I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" : :
"r" (freq));
Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
But unfortunately Xen fails on both this instructions with "Undefined
instruction" exception.
You can see log in attachment.
Could you plea
On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >>> On 16.01.15 at 16:56, wrote:
> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> > On 06.01.15 at 14:41, wrote:
> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
> Instead of copying data for each field in xen_sysctl_topologyinfo
>
On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a s
On Fri, 16 Jan 2015, Andrew Cooper wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
>
> Signed-off-by: Andrew Cooper
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Ian Campbell
> CC: Stefano Stabellini
> CC: Tim Deegan
>
For the tiny arm pa
Stefano Stabellini writes ("[PATCH] Switch QEMU_UPSTREAM_REVISION back to
master"):
> Signed-off-by: Stefano Stabellini
>
> diff --git a/Config.mk b/Config.mk
> index 0e22057..4745b85 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?=
> git://xenbits.xen.or
>>> On 16.01.15 at 16:56, wrote:
> On 01/07/2015 04:12 AM, Jan Beulich wrote:
> On 06.01.15 at 14:41, wrote:
>>> On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo
separately
put cpu/socket/node into a single structure a
Signed-off-by: Stefano Stabellini
diff --git a/Config.mk b/Config.mk
index 0e22057..4745b85 100644
--- a/Config.mk
+++ b/Config.mk
@@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?=
git://xenbits.xen.org/qemu-xen-unstable.git
SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
endif
OVMF_UPST
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.
There is also no
On Fri, Jan 16, 2015 at 3:19 PM, Julien Grall
wrote:
> Hi Iurii,
>
Hi Julien
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
> > +static int __init rcar2_uart_init(struct dt_device_node *dev,
> > + const void *data)
> > +{
> > +const char *config = data;
> > +
> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Thursday, January 15, 2015 11:49 PM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xe
On 16/01/15 15:29, Iurii Konovalenko wrote:
>> Is there any reason that this code diverge?
>>
>
> Linux kernel 3.14-ltsi, which I used as a reference, use CNTFID0
> in file arch/arm/mach-shmobile/setup-rcar-gen2.c:
> iowrite32(freq, base + CNTFID0);
Which seems different from upstream:
1. /* Upd
Hi, Julien.
On Fri, Jan 16, 2015 at 4:08 PM, Julien Grall
wrote:
> Hi Iurii,
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
>> From: Iurii Konovalenko
>>
>> Signed-off-by: Iurii Konovalenko
>> ---
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/shmobile.c
Hello Manish,
recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
working together on ARM. He wrote the following wiki page:
https://wiki.linaro.org/OpenStack/DevstackOnXenARM
Cheers,
Stefano
On Fri, 16 Jan 2015, Jaggi, Manish wrote:
> Hi Jim,
>
>
> I am trying to run libvirtd
>>> On 16.01.15 at 15:24, wrote:
> On ARM, the way to assign device tree node is exactly the same as PCI.
> Futhermore, all devices can be represented by a 'device_t'.
> Therefore there is no need to add separate ops.
>
> The x86 iommu drivers has not been modified to replace 'struct pci_dev'
> b
On Fri, Jan 16, 2015 at 02:47:42PM +, Ian Campbell wrote:
> On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> > On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > > Hello,
> > >
> > > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > > +# define VI
Hi Jan,
On 16/01/15 14:59, Jan Beulich wrote:
On 16.01.15 at 15:24, wrote:
>> ---
>> xen/common/device.c | 21 +
>> xen/common/device_tree.c | 3 +++
>
> Is there a Makefile change missing here?
No. The file common/device.c should not be there. I drop fo
>>> On 16.01.15 at 15:24, wrote:
> ---
> xen/common/device.c | 21 +
> xen/common/device_tree.c | 3 +++
Is there a Makefile change missing here?
> --- /dev/null
> +++ b/xen/common/device.c
> @@ -0,0 +1,21 @@
> +#include
> +#include
> +
> +void device_initia
On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > Hello,
> >
> > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > +# define VIR_WARNINGS_NO_PRINTF \
> > > +_Pragma ("GCC diagnostic push") \
> > >
On 16/01/15 11:17, Ian Jackson wrote:
The latter is the GPF turning out to be unreproducible.
I guess we should keep an eye out in case it turns out to be a race
rather than a cosmic ray.
I do not believe in cosmic rays.
Some notes in case it resurfaces:
1) the topmost caller address appears
Hi everyone,
I just wanted to let you know that
a) the website for the developer summit is up and running now :
http://events.linuxfoundation.org/events/xen-project-developer-summit/
b) the CfP is also open now at
http://events.linuxfoundation.org/events/xen-project-developer-summit/program/cfp
It is no good idea to have bitfields in the same byte which are modified
with different locks held (or, in this case, one with lock and one
without). Use at least bytes for this purpose.
Signed-off-by: Juergen Gross
diff -r 3feb5ddb5434 drivers/xen/scsifront/common.h
--- a/drivers/xen/scsifront/
Some drivers may want to configure differently the device depending on
the compatible string.
Also modify the return type of dt_match_node to return the matching
structure.
Signed-off-by: Julien Grall
---
xen/arch/arm/platform.c | 2 +-
xen/common/device_tree.c | 12 ++--
xe
Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.
Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.
Signed-off-by: Julien G
Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.
Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.
Signed-off-by: Julien Grall
---
From: Andreas Herrmann
Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so fa
From: Andreas Herrmann
If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.
So better check for duplicates when DT info
The current SMMU driver has completly diverged. That makes me hard to
maintain.
Signed-off-by: Julien Grall
---
xen/drivers/passthrough/arm/Makefile |1 -
xen/drivers/passthrough/arm/smmu.c | 1784 --
2 files changed, 1785 deletions(-)
delete mode 100644 xe
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify whe
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.
Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.
Rather than req
Hello,
The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.
With this series, the code of the SMMU drivers (copied from Linux) is mostly
not modified. If it's the case a comment /* Xen:
On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a 'device_t'.
Therefore there is no need to add separate ops.
The x86 iommu drivers has not been modified to replace 'struct pci_dev'
by "device_t" because the latter is an alias of
The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v2.c | 1 -
xen/arch/arm/vgic-v3.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/xen/arch/
1 - 100 of 151 matches
Mail list logo
