Hi,
On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initializ
Hi Julien,
>>> Hi Jan,
>>>
> @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
> unsigned int domcr_flags,
> if ( (rc = domain_vtimer_init(d, config)) != 0 )
> goto fail;
>
> +if ( domcr_flags & DOMCRF_vuart )
> +if ( (rc = domain_vp
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more.
It is still necessary for old Xen versions (< 4.0) and for being able
to run the Linux kernel as dom0 in a nested
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more. As commit da72ff5bfcb0
("partially revert xen: Remove event channel notification through Xen
PCI platform device")
On 04/05/17 14:35, Jan Beulich wrote:
> Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
> assembly") didn't go quite far enough with the cleanup it did: The
> changed maximum frame size should also have been reflected in the early
> address range check (which has now been pointed o
At 13:53 +0100 on 04 May (1493905990), Ian Jackson wrote:
> To become a CNA (CVE Numbering Authority), which we would like to do,
> we need to provide MITRE's CNA programme with a definition of the
> scope of our CNA. That should be the scope of our general security
> support, clearly.
>
> At the
flight 71257 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71257/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
Hi Daniel,
On 5 May 2017 at 00:00, Daniel Kiper wrote:
> Hey,
>
> On Tue, May 02, 2017 at 03:06:24PM +0800, fu@linaro.org wrote:
>> From: Fu Wei
>>
>> This patchset add xen_boot support into grup-mkconfig for
>> generating xen boot entrances automatically
>>
>> Also update the docs/grub.texi
On 03/05/17 22:20, Boris Ostrovsky wrote:
> Routines that are set by xen_init_time_ops() use shared_info's
> pvclock_vcpu_time_info area. This area is not properly available until
> shared_info is mapped in xen_setup_shared_info().
>
> This became especially problematic due to commit dd759d93f4dd
Hi Stefano,
On 4 May 2017 at 04:53, Stefano Stabellini wrote:
> On Wed, 3 May 2017, Andrew Cooper wrote:
>> On 02/05/17 08:06, fu@linaro.org wrote:
>> > From: Fu Wei
>> >
>> > This patch adds the support of xen_boot command for aarch64:
>> > xen_hypervisor
>> > xen_module
>> > These
Hi,
On 04/05/17 17:21, Julien Grall wrote:
> Hi Andre,
>
> On 04/05/17 16:31, Andre Przywara wrote:
>> Introduce the proper locking sequence for the new pending_irq lock.
>> This takes the lock around multiple accesses to struct members,
>> also makes sure we observe the locking order (VGIC VCPU
> On 5 May 2017, at 09:43, Tim Deegan wrote:
>
> At 13:53 +0100 on 04 May (1493905990), Ian Jackson wrote:
>> To become a CNA (CVE Numbering Authority), which we would like to do,
>> we need to provide MITRE's CNA programme with a definition of the
>> scope of our CNA. That should be the scope
On 05/05/17 09:57, Fu Wei wrote:
> Hi Stefano,
>
> On 4 May 2017 at 04:53, Stefano Stabellini wrote:
>> On Wed, 3 May 2017, Andrew Cooper wrote:
>>> On 02/05/17 08:06, fu@linaro.org wrote:
From: Fu Wei
This patch adds the support of xen_boot command for aarch64:
xen_hy
Hi Andrew,
On 5 May 2017 at 17:01, Andrew Cooper wrote:
> On 05/05/17 09:57, Fu Wei wrote:
>> Hi Stefano,
>>
>> On 4 May 2017 at 04:53, Stefano Stabellini wrote:
>>> On Wed, 3 May 2017, Andrew Cooper wrote:
On 02/05/17 08:06, fu@linaro.org wrote:
> From: Fu Wei
>
> This pat
Commit 897129deab ("x86: use unambiguous register names") went a little
too far: With it we also get register names like _e15 and e15 for
non-Xen consumers using a gcc compatible compiler. Correct this.
Signed-off-by: Jan Beulich
--- a/xen/include/public/arch-x86/xen-x86_64.h
+++ b/xen/include/p
Hi,
At 09:59 +0100 on 05 May (1493978382), Lars Kurth wrote:
> > On 5 May 2017, at 09:43, Tim Deegan wrote:
> > - Only features listed as Supported in MAINTAINERS get support.
>
> This seems related to George's proposal of the scope. I am not sure
> MAINTAINERS is correct though (e.g. live-patc
>>> On 05.05.17 at 10:41, wrote:
> On 04/05/17 14:35, Jan Beulich wrote:
>> @@ -345,24 +344,30 @@ UNLIKELY_START(z, create_bounce_frame_ba
>> __UNLIKELY_END(create_bounce_frame_bad_bounce_ip)
>> movq %rax,UREGS_rip+8(%rsp)
>> ret
>> -_ASM_EXTABLE(.Lft2, domain_crash_pa
Hi Stefano,
>> >> >> > It looks like you are reusing the libxl__device_console_add call for
>> >> >> > the
>> >> >> > main PV console for the domain, to also add the vuart nodes to
>> >> >> > xenstore.
>> >> >> >
>> >> >> > I don't think it is a good idea to mix the two. I suggest to
>> >> >> >
Hi Andrew,
On 05/05/17 10:01, Andrew Cooper wrote:
On 05/05/17 09:57, Fu Wei wrote:
Hi Stefano,
On 4 May 2017 at 04:53, Stefano Stabellini wrote:
On Wed, 3 May 2017, Andrew Cooper wrote:
On 02/05/17 08:06, fu@linaro.org wrote:
From: Fu Wei
This patch adds the support of xen_boot comm
On 05/05/17 10:27, Jan Beulich wrote:
> Commit 897129deab ("x86: use unambiguous register names") went a little
> too far: With it we also get register names like _e15 and e15 for
> non-Xen consumers using a gcc compatible compiler. Correct this.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Co
>>> On 04.05.17 at 23:30, wrote:
> Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
> Protection Fault and thus results in a hypervisor crash. This behavior has
> been observed on two generations of Intel processors namely, Haswell and
> Broadwell. Other Intel processor gen
On 05/05/17 10:38, Jan Beulich wrote:
On 05.05.17 at 10:41, wrote:
>> On 04/05/17 14:35, Jan Beulich wrote:
>>> @@ -345,24 +344,30 @@ UNLIKELY_START(z, create_bounce_frame_ba
>>> __UNLIKELY_END(create_bounce_frame_bad_bounce_ip)
>>> movq %rax,UREGS_rip+8(%rsp)
>>> ret
>>>
>>> On 04.05.17 at 19:09, wrote:
> On 05/04/2017 11:31 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -1035,16 +1035,82 @@ merge_and_free_buddy(struct page_info *pg, unsigned
>>> int node,
>>> return pg;
>
>>> On 05.05.17 at 12:18, wrote:
> On 05/05/17 10:38, Jan Beulich wrote:
> On 05.05.17 at 10:41, wrote:
>>> On 04/05/17 14:35, Jan Beulich wrote:
@@ -345,24 +344,30 @@ UNLIKELY_START(z, create_bounce_frame_ba
__UNLIKELY_END(create_bounce_frame_bad_bounce_ip)
movq %ra
>>> On 04.05.17 at 19:18, wrote:
> On 05/04/2017 11:43 AM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> While scrubbing from idle loop, check for softirqs every 256 pages.
>>> If softirq is pending, don't scrub any further and merge the
>>> partially-scrubbed buddy back into heap by
On 05/05/17 11:24, Jan Beulich wrote:
On 05.05.17 at 12:18, wrote:
>> On 05/05/17 10:38, Jan Beulich wrote:
>> On 05.05.17 at 10:41, wrote:
On 04/05/17 14:35, Jan Beulich wrote:
> @@ -345,24 +344,30 @@ UNLIKELY_START(z, create_bounce_frame_ba
> __UNLIKELY_END(create_bounce_
>>> On 04.05.17 at 19:26, wrote:
> On 05/04/2017 12:03 PM, Jan Beulich wrote:
> On 14.04.17 at 17:37, wrote:
>>> Instead of scrubbing pages while holding heap lock we can mark
>>> buddy's head as being scrubbed and drop the lock temporarily.
>>> If someone (most likely alloc_heap_pages()) tri
Hi Julien,
On 5 May 2017 at 18:11, Julien Grall wrote:
> Hi Andrew,
>
>
> On 05/05/17 10:01, Andrew Cooper wrote:
>>
>> On 05/05/17 09:57, Fu Wei wrote:
>>>
>>> Hi Stefano,
>>>
>>> On 4 May 2017 at 04:53, Stefano Stabellini
>>> wrote:
On Wed, 3 May 2017, Andrew Cooper wrote:
>
Hello Stefano,
On 24.04.17 21:08, Stefano Stabellini wrote:
Stubdomains (stubdoms in short) are small domains, each running a single
application. Typically they run unikernels rather than a full fledged
operating system. A classic example is QEMU stubdoms on x86: one QEMU
stubdoms is started for
On 24.04.17 21:08, Stefano Stabellini wrote:
If we are speaking about shared coprocessors framework, we need here several
things:
- MMIO access emulation
This could be run as EL0 app.
But even now, the MMIO access emulation has something to do with the
real hardware under the circumstances
Hi Julien,
>> +
>> +unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
>
>
> This should be static. But I don't get what you need that. In the first
> version, I suggested to re-purpose vgic_reg*_{extract,update} so we can use
> it here. It would probably need to be renamed to vreg_reg*.
flight 109003 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 107358
build-amd64-pvops
flight 109014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109014/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Hi,
On 05/05/17 11:13, Andrew Cooper wrote:
On 05/05/17 10:27, Jan Beulich wrote:
Commit 897129deab ("x86: use unambiguous register names") went a little
too far: With it we also get register names like _e15 and e15 for
non-Xen consumers using a gcc compatible compiler. Correct this.
Signed-of
On 05/05/2017 01:41 AM, Lu Baolu wrote:
> Hi,
>
> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>> Add a simple udelay calibration in x86 architecture-specific
>>> boot-time initializations. This will get a workable estimate
>>> for loops_per_jiffy. Henc
Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
assembly") didn't go quite far enough with the cleanup it did: The
changed maximum frame size should also have been reflected in the early
address range check (which has now been pointed out to have been wrong
anyway, using 60 instead
While using alloc_domheap_pages() and assuming the allocated memory is
directly accessible is okay at boot time (as we run on the idle page
tables there), memory hotplug code too assumes it can access the
resulting page tables without using map_domain_page() or alike, and
hence we need to obtain me
On 05/05/17 12:18, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
+
+unsigned int vpl011_reg_mask[] = {0xff, 0x, 0x};
This should be static. But I don't get what you need that. In the first
version, I suggested to re-purpose vgic_reg*_{extract,update} so we can use
it here.
flight 109011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 108170
build-i386-pvops
+bool scrub_free_pages(void)
{
struct page_info *pg;
unsigned int zone, order;
unsigned long i;
+unsigned int cpu = smp_processor_id();
+bool preempt = false;
+nodeid_t node;
-ASSERT(spin_is_locked(&heap_lock));
>>
On 05/05/17 08:10, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
Hi Jan,
@@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
unsigned int domcr_flags,
if ( (rc = domain_vtimer_init(d, config)) != 0 )
goto fail;
+if ( domcr_flags & DOMCRF_vuart )
+if (
On 04/05/17 16:50, Andrii Anisov wrote:
Julien,
Hi Andrii,
What I would like to understand is what are the information that the
hypervisors as to know for sharing co-processor? So far I have:
- MMIOs
- Interrupts
Anything else?
IOMMU bindings.
This knowledge enough to get the physi
On 05/05/2017 06:27 AM, Jan Beulich wrote:
On 04.05.17 at 19:18, wrote:
>> On 05/04/2017 11:43 AM, Jan Beulich wrote:
>> On 14.04.17 at 17:37, wrote:
While scrubbing from idle loop, check for softirqs every 256 pages.
If softirq is pending, don't scrub any further and merge the
>>> On 05.05.17 at 15:42, wrote:
Otoh there's not much to scrub yet until Dom0 had all its memory
allocated, and we know which pages truly remain free (wanting
what is currently the boot time scrubbing done on them). But that
point in time may still be earlier than when we swit
>>> On 05.05.17 at 15:51, wrote:
> On 05/05/2017 06:27 AM, Jan Beulich wrote:
> On 04.05.17 at 19:18, wrote:
>>> On 05/04/2017 11:43 AM, Jan Beulich wrote:
>>> On 14.04.17 at 17:37, wrote:
> While scrubbing from idle loop, check for softirqs every 256 pages.
> If softirq is pendi
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of attack
from a domain privileged enough to run domains?
Whilst the domain is privileged enough to ru
>>> On 05.05.17 at 16:10, wrote:
On 05.05.17 at 15:42, wrote:
> Otoh there's not much to scrub yet until Dom0 had all its memory
> allocated, and we know which pages truly remain free (wanting
> what is currently the boot time scrubbing done on them). But that
> point in time
Julien Grall writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> I have CCed Ian and Wei to comment on the difficult to describe a such
> interface in libxl. They may have insights how to do this properly.
Hi.
> @Ian @Wei: Andrii is suggesting to use Device-Tree for des
On 04/05/17 10:00, Razvan Cojocaru wrote:
> This small series first creates hvm/vm_event.{h,c}, in order to bring
> under vm_event maintainership the code that has previously lived in
> hvm_do_resume(), and then fixes a __context_switch()-related race
> condition when attempting to set registers vi
On 05/05/2017 10:14 AM, Jan Beulich wrote:
On 05.05.17 at 16:10, wrote:
> On 05.05.17 at 15:42, wrote:
>> Otoh there's not much to scrub yet until Dom0 had all its memory
>> allocated, and we know which pages truly remain free (wanting
>> what is currently the boot time scrub
Hi all,
This small patch series ensure that Xen will not die when receiving unknown
trap from the guests. I am not aware of any issue with platform we currently
support, so I am not sure whether it would be Xen 4.9 material.
Cheers,
Julien Grall (3):
xen/arm: arm32: Rename the trap to the corr
Per Table B1-3 in ARM DDI 0406C.c, the vector 0x8 for hyp is called
"Hypervisor Call".
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/arm32/entry.S | 4 ++--
xen/arch/arm/arm32/traps.c | 4 ++--
2 files ch
The function do_trap_hypervisor is currently handling both trap coming
from the hypervisor and the guest. This makes difficult to get specific
behavior when a trap is coming from either the guest or the hypervisor.
Split the function into two parts:
- do_trap_guest_sync to handle guest traps
Currently we crash Xen if we see an ESR_EL2.EC value we don't recognise.
As configurable disables/enables are added to the architecture
(controlled by RES1/RESO bits respectively), with associated synchronous
exceptions, it may be possible for a guest to trigger exceptions with
classes that we don'
>>> On 05.05.17 at 05:52, wrote:
> 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> outstanding p2m_ioreq_server entries")' will call
> p2m_change_entry_type_global() which set entry.recalc=1. Then
> the following get_entry(p2m_ioreq_server) will return
> p2m_ram_rw type.
> But 'com
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Thu, 4 May 2017 14:23:04 +0200
>
>> Unavoidable crashes in netfront_resume() and netback_changed() after a
>> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
>> xenstore) were discovered. The failure path in talk_to_ne
On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
On 04.05.17 at 17:17, wrote:
>> On 05/04/17 17:57, Tamas K Lengyel wrote:
>>> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
>>> On 04.05.17 at 11:14, wrote:
> On 05/04/17 12:11, Jan Beulich wrote:
> On 04.05.17 at 11:
>>> On 05.05.17 at 16:42, wrote:
> On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
> On 04.05.17 at 17:17, wrote:
>>> On 05/04/17 17:57, Tamas K Lengyel wrote:
On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
On 04.05.17 at 11:14, wrote:
>> On 05/04/17 12:11, Jan Be
On 05/05/17 14:11, Jan Beulich wrote:
> Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from
> assembly") didn't go quite far enough with the cleanup it did: The
> changed maximum frame size should also have been reflected in the early
> address range check (which has now been pointed o
Replace bool_t with bool.
Change check_stack_limit to return bool.
Fix some coding style issues.
Undef TOGGLE_MODE when it is no longer needed.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/emulate_ops.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff -
The following handlers are moved:
1. do_set_trap_table
2. do_set_debugreg
3. do_get_debugreg
4. do_fpu_taskswitch
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 97 +
xen/arch/x86/traps.c| 94 ---
Put it along side with other pv_inject functions and rename it to
pv_inject_trap.
We need this because this function is used by PV emulation code and PV
trap handling code, which will be split into different files.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c |
The body of subarch_percpu_traps_init is for setting up PV syscall
trampoline. Move that into a dedicated function.
Leave the BUILD_BUG_ON in the original function as it is not tied to PV.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 13 +
1 file c
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 37 +
xen/arch/x86/traps.c| 36
2 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 63 +
xen/arch/x86/traps.c| 59 -
2 files changed, 63 insertions(+), 59 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/
This series splits PV code related to trap handling to files under pv
directory.
The patches to refactor various entry.S are dropped in this version as Andrew
is going to work on those.
git://xenbits.xen.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 27 +++
xen/arch/x86/traps.c| 27 ---
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 9de5798e58
It will be used in common and pv specific code. Export it in traps.h.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c| 2 +-
xen/include/asm-x86/traps.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.
>>> On 05.05.17 at 16:27, wrote:
> On 05/05/2017 10:14 AM, Jan Beulich wrote:
> On 05.05.17 at 16:10, wrote:
>> On 05.05.17 at 15:42, wrote:
>>> Otoh there's not much to scrub yet until Dom0 had all its memory
>>> allocated, and we know which pages truly remain free (wanting
>>> On 14.04.17 at 17:37, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -114,6 +114,13 @@ config DEVICE_TREE_DEBUG
> logged in the Xen ring buffer.
> If unsure, say N here.
>
> +config SCRUB_DEBUG
> +bool "Page scrubbing test"
> +default DEBUG
> +---
On 05/05/17 14:12, Jan Beulich wrote:
> While using alloc_domheap_pages() and assuming the allocated memory is
> directly accessible is okay at boot time (as we run on the idle page
> tables there), memory hotplug code too assumes it can access the
> resulting page tables without using map_domain_p
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 18 ++
xen/arch/x86/traps.c| 18 --
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 54d77922c5..4e9a376000 10064
Fixed some coding style issues while moving.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 50 +
xen/arch/x86/traps.c| 47 --
2 files changed, 50 insertions(+), 47 deleti
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 4 ++--
xen/include/asm-x86/traps.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 8aa4d9e335..c946d855c3 100644
--- a/xen/arch/x86/p
It needs to be non-static when we split PV specific code out.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c| 2 +-
xen/include/asm-x86/traps.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2
Move them to pv/traps.c.
This in turn requires exporting pv_percpu_traps_init and
hypercall_page_initialise_ring3_kernel.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 363
xen/arch/x86/x86_64/traps.c | 363 +
Replace bool_t with bool. Delete trailing white spaces. Fix some coding
style issues.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/traps.c | 77 +++-
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/xen/arch/x86/tra
Fix coding style issues.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 8cabef7a44..8aa4d9e335 100644
--- a/xen/arch/
Export hypercall_page_initialise_ring1_kernel as the code is moved.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/traps.c| 406
xen/arch/x86/x86_64/compat/traps.c | 415 -
xen/arch/x86/x86_64
And provide an Emacs block.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/traps.h | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 7f36f6c1a7..0676e81d1a 100644
--- a/xen/include/asm-x86/tra
On 05/05/2017 10:51 AM, Jan Beulich wrote:
On 05.05.17 at 16:27, wrote:
>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>> On 05.05.17 at 16:10, wrote:
>>> On 05.05.17 at 15:42, wrote:
Otoh there's not much to scrub yet until Dom0 had all its memory
allocated, and we
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of
attack
from a domain privileged enough to run
On Fri, May 5, 2017 at 10:47 AM, Jan Beulich wrote:
On 05.05.17 at 16:42, wrote:
>> On Thu, May 4, 2017 at 11:37 AM, Jan Beulich wrote:
>> On 04.05.17 at 17:17, wrote:
On 05/04/17 17:57, Tamas K Lengyel wrote:
> On Thu, May 4, 2017 at 5:22 AM, Jan Beulich wrote:
> On
The pin_page block is missing one level of indentation, which makes the
MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
While making this adjustment, delete one other piece of trailing whitespace.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domain.c | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ef8c05a..862a568 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1886,8 +1886,6 @@ static void
On Fri, May 05, 2017 at 04:51:02PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 05/05/2017 01:09 AM, Juergen Gross wrote:
> Any comments?
>
>
> Juergen
>
> On 27/04/17 07:01, Juergen Gross wrote:
>> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
>> on AMD cpus.
>>
>> This bug/feature bit is kind of special as it will be used very early
>> when switchin
>>> On 05.05.17 at 17:23, wrote:
> On 05/05/2017 10:51 AM, Jan Beulich wrote:
> On 05.05.17 at 16:27, wrote:
>>> On 05/05/2017 10:14 AM, Jan Beulich wrote:
>>> On 05.05.17 at 16:10, wrote:
On 05.05.17 at 15:42, wrote:
> Otoh there's not much to scrub yet until Dom0 had
>>> On 05.05.17 at 17:51, wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
I too had this on my mental list for killing...
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 05/05/17 17:07, Jan Beulich wrote:
On 05.05.17 at 17:51, wrote:
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
>
> I too had this on my mental list for killing...
I have lost count of the number of times I've looked at it and decided
that I really should get around to deleting
>>> On 05.05.17 at 17:51, wrote:
> The pin_page block is missing one level of indentation, which makes the
> MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
>
> While making this adjustment, delete one other piece of trailing whitespace.
>
> No functional change.
>
>
On 05/05/17 15:48, Wei Liu wrote:
> The body of subarch_percpu_traps_init is for setting up PV syscall
> trampoline. Move that into a dedicated function.
>
> Leave the BUILD_BUG_ON in the original function as it is not tied to PV.
>
> No functional change.
>
> Signed-off-by: Wei Liu
The trampolin
The pin_page block is missing one level of indentation, which makes the
MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
However, the block isn't needed at all if page is declared with switch level
scope. This allows for the removal of the identical local declarations f
On Fri, May 05, 2017 at 05:32:43PM +0100, Andrew Cooper wrote:
> The pin_page block is missing one level of indentation, which makes the
> MMUEXT_UNPIN_TABLE case label appear to be outside of the switch statement.
>
> However, the block isn't needed at all if page is declared with switch level
>
On 05/05/2017 12:05 PM, Jan Beulich wrote:
On 05.05.17 at 17:23, wrote:
>> On 05/05/2017 10:51 AM, Jan Beulich wrote:
>> On 05.05.17 at 16:27, wrote:
On 05/05/2017 10:14 AM, Jan Beulich wrote:
On 05.05.17 at 16:10, wrote:
> On 05.05.17 at 15:42, wrote:
>>
Hello Ian,
On 05.05.17 17:13, Ian Jackson wrote:
I read this proposal.
I agree that putting all the details (interrupts, mmio, etc.) in the
libxl config file is probably undesirable.
AFAICT, there, a particularly coprocessor can be identified as a
portion of the host's DT. Is that right ? T
Andrii Anisov writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> On 05.05.17 17:13, Ian Jackson wrote:
> > If these regions of the DT can be marked by this "xen,coproc"
> > property, can't we instead identify them (eg in the libxl domain
> > configuration) by their DT pat
On 05/05/2017 04:27 PM, Andrii Anisov wrote:
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared o
On Fri, May 05, 2017 at 09:59:15AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
>
> It is still necessary for old Xen versio
On Fri, May 05, 2017 at 10:00:36AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert x
1 - 100 of 128 matches
Mail list logo
