On 14/02/2017 02:52, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Monday, February 13, 2017 10:32 PM
>>
>> hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
>> restored when switching into guest context. It should never have been p
flight 105778 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs. 592
flight 105782 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105782/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b97eb4c35316cbe8235ae526209263da818e1a4
baseline version:
ovmf 296153c5bf9976a3b5f00
Hi,
I am interested to restart Hosted Xen Project.
I have gone through the presentation of Hosted Xen and Ian Pratt's video in
Xen Summit 9.
I have secured the source code for HostedXen from
https://downloads.xen.org/HostedXen/release/
Tried to build it on windows but its failing.
It would be of
flight 105777 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 3 host-install(3)broken REGR. vs. 105756
build-amd64-xsm
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, February 13, 2017 9:04 PM
>
> Sending an invalidation to the device model is an internal detail of
> completing the hypercall; callers should not need to be responsible for it.
> Drop HVM_HCALL_invalidate entirely and call se
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, February 13, 2017 10:33 PM
>
> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
> SYSCALL_MASK state is unconditionally loaded when switching into guest
> context.
>
> Attempting to dirty-track the state is
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, February 13, 2017 10:32 PM
>
> A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
> moving in and out of HVM vcpu context. Two of these values are compile time
> constants, and the third is directly
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, February 13, 2017 10:32 PM
>
> hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
> restored when switching into guest context. It should never have been part of
> the migration state to start with,
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 13, 2017 10:21 PM
>
> There is an issue with the original __vmread() in nested vmx mode:
> emulation of a guest's VMREAD with invalid arguments leads to BUG().
>
> Fix this by using vmread_safe() and reporting any ki
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 13, 2017 10:21 PM
>
> There is an issue with the original __vmwrite() in nested vmx mode:
> emulation of a guest's VMWRITE with invalid arguments leads to BUG().
>
> Fix this by using vmwrite_safe() and reporting any
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 13, 2017 10:21 PM
>
> The new value corresponds to VMsucceed status of VMX instructions.
> This will replace usage of literal zeroes in related functions.
>
> Update vmfail(), vmread_safe() and vmwrite_safe().
>
> S
vpmu_enable() can not use for check if vpmu is enabled in guest during
booting up. Because linux kernel get the status of if supported pmu
is earler than xen vpmu initialise. vpmu_enable() will return false
even if vpmu has been enabled in guest.
Signed-off-by: Luwei Kang
---
xen/arch/x86/cpu/vp
On February 13, 2017 4:24 PM, Tian, Kevin wrote:
>> From: Tian, Kevin
>> Sent: Monday, February 13, 2017 4:21 PM
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Wednesday, February 08, 2017 4:52 PM
>> >
>> > >>> On 08.02.17 at 09:27, wrote:
>> > > Assumed vCPU is in guest_mode..
>>
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Instead of directly manipulating the tables in memory, an ITS driver
> sends commands via a ring buffer to the ITS h/w to create or alter the
> LPI mappings.
> Allocate memory for that buffer and tell the ITS about it to be able
> to send ITS commands.
>
On Mon, 6 Feb 2017, Julien Grall wrote:
> > +static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
> > +{
> > +uint64_t ret;
> > +
> > +if ( page_bits < 16 )
> > +return (uint64_t)addr & GENMASK(47, page_bits);
> > +
> > +ret = addr & GENMASK(47, 16);
> > +return ret
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
> an EventID (the MSI payload or interrupt ID) to a pair of LPI number
> and collection ID, which points to the target CPU.
> This mapping is stored in the device and collection table
On Mon, 30 Jan 2017, Andre Przywara wrote:
> The ARM GICv3 provides a new kind of interrupt called LPIs.
> The pending bits and the configuration data (priority, enable bits) for
> those LPIs are stored in tables in normal memory, which software has to
> provide to the hardware.
> Allocate the requ
flight 105775 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 105279
R
On Fri, 10 Feb 2017, Stefano Stabellini wrote:
> Concurrent execution of gic_update_one_lr and vgic_store_itargetsr can
> result in the wrong pcpu being set as irq target, see
> http://marc.info/?l=xen-devel&m=148218667104072.
>
> To solve the issue, add barriers, remove an irq from the inflight
>
On Tue, 7 Feb 2017, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Stop blacklisting ZynqMP's power management node.
> This is now possible since we allow the hardware domain to
> issue HVC/SMC calls to firmware.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
On Tue, 7 Feb 2017, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Implement an EEMI mediator and forward platform specific
> firmware calls from guests to firmware.
>
> The EEMI mediator is responsible for implementing access
> controls modifying or blocking calls that try to operate
flight 105767 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl
On February 13, 2017 2:34:01 PM PST, Waiman Long wrote:
>On 02/13/2017 04:52 PM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>>> On 02/13/2017 02:42 PM, Waiman Long wrote:
On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 11:
On 02/13/2017 04:52 PM, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>> On 02/13/2017 02:42 PM, Waiman Long wrote:
>>> On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
> That way we'd end u
On Mon, Feb 13, 2017 at 05:24:36PM -0500, Waiman Long wrote:
> >> movsql %edi, %rax;
> >> movq __per_cpu_offset(,%rax,8), %rax;
> >> cmpb $0, %[offset](%rax);
> >> setne %al;
> I have thought of that too. However, the goal is to eliminate memory
> read/write from/to stack. Eliminating a register
On 02/13/2017 03:06 PM, h...@zytor.com wrote:
> On February 13, 2017 2:53:43 AM PST, Peter Zijlstra
> wrote:
>> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>>> That way we'd end up with something like:
>>>
>>> asm("
>>> push %rdi;
>>> movslq %edi, %rdi;
>>> movq __per_cpu_offs
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
> wrote:
> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> >> On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
> >> wrote:
> >> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> >> >> On Mon, Feb 13
On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
wrote:
> On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
>> On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
>> wrote:
>> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
>> >> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall
>> >> wrote:
>> >> >
>>
On Tue, 7 Feb 2017, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Introduce call_smcc64, a helper function to issue 64-bit SMC
> calls that follow the SMC Calling Convention. This includes
> returning up to 4 64-bit values.
>
> Signed-off-by: Edgar E. Iglesias
Please write it in ass
On February 13, 2017 1:52:20 PM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>> On 02/13/2017 02:42 PM, Waiman Long wrote:
>> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
>> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> >>> Th
On Tue, 7 Feb 2017, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Introduce platform_hvc as a way to handle hypercalls that
> Xen does not know about in a platform specific way. This
> is particularly useful for implementing the SiP (SoC
> implementation specific) service calls.
>
> S
On Tue, 7 Feb 2017, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Move the early setting of PSCI_RESULT_REG to a later stage
> avoiding the early override of the FID that's stored in
> the same register.
>
> No functional change.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: St
On February 13, 2017 1:52:20 PM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>> On 02/13/2017 02:42 PM, Waiman Long wrote:
>> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
>> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> >>> Th
On Mon, Feb 13, 2017 at 12:06:44PM -0800, h...@zytor.com wrote:
> >Maybe:
> >
> >movsql %edi, %rax;
> >movq __per_cpu_offset(,%rax,8), %rax;
> >cmpb $0, %[offset](%rax);
> >setne %al;
> >
> >?
>
> We could kill the zero or sign extend by changing the calling
> interface to pass an unsigned long i
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
> wrote:
> > On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> >> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall
> >> wrote:
> >> >
> >> >
> >> > On 13/02/17 16:59, Tamas K Lengyel wrote:
> >> >>
> >> >
On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
> On 02/13/2017 02:42 PM, Waiman Long wrote:
> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
> >>> That way we'd end up with something like:
> >>>
> >>> asm("
> >>> pu
On Mon, 13 Feb 2017, Bhupinder Thakur wrote:
> Hi Stefano,
>
> On 9 February 2017 at 05:40, Stefano Stabellini
> wrote:
> > On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
> >> Hi Julien,
> >>
> >> On 3 February 2017 at 19:38, Julien Grall wrote:
> >> > So if I understand correctly, you don't recei
On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
wrote:
> On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
>> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall wrote:
>> >
>> >
>> > On 13/02/17 16:59, Tamas K Lengyel wrote:
>> >>
>> >> On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall
>> >> wrote:
>> >>>
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall wrote:
> >
> >
> > On 13/02/17 16:59, Tamas K Lengyel wrote:
> >>
> >> On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall
> >> wrote:
> >>>
> >>> Hi Tamas,
> >>>
> >>>
> >>> On 13/02/17 16:20, Tamas K Lengyel
flight 105766 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-installfail REGR. vs. 105756
Regressions which
On 02/13/2017 02:42 PM, Waiman Long wrote:
> On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>>> That way we'd end up with something like:
>>>
>>> asm("
>>> push %rdi;
>>> movslq %edi, %rdi;
>>> movq __per_cpu_offset(,%rdi,8), %rax;
>
On February 13, 2017 2:53:43 AM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> That way we'd end up with something like:
>>
>> asm("
>> push %rdi;
>> movslq %edi, %rdi;
>> movq __per_cpu_offset(,%rdi,8), %rax;
>> cmpb $0, %[offset](%rax);
>> setne
On Mon, 13 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 10/02/17 01:01, Stefano Stabellini wrote:
> > On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
> > > A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA.
> > > PCI DMA devs could be locked in to only be able to access
On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall wrote:
>
>
> On 13/02/17 16:59, Tamas K Lengyel wrote:
>>
>> On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall
>> wrote:
>>>
>>> Hi Tamas,
>>>
>>>
>>> On 13/02/17 16:20, Tamas K Lengyel wrote:
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Bab
Changes in v5:
- add padding after out_prod
- add "Why ring.h is not needed"
- specify max-ring-page-order >= 1
Changes in v4:
- Backend XenBus Nodes first
- add version negotiation
- remove complex optimization to avoid unnecessary event notifications
- move out indexes to separate cacheline
- ma
Changes in v9:
- specify max-page-order must be >= 1
- clarifications
- add "Expanding the protocol"
- add padding after out_error
- add "Why ring.h is not needed"
Changes in v8:
- introduce the concept of indexes page
- many clarifications
- add a diagram
- introduce support for multiple versions
On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> That way we'd end up with something like:
>>
>> asm("
>> push %rdi;
>> movslq %edi, %rdi;
>> movq __per_cpu_offset(,%rdi,8), %rax;
>> cmpb $0, %[offset](%rax);
>> setne %al;
>> pop %rd
On 02/13/2017 05:47 AM, Peter Zijlstra wrote:
> On Fri, Feb 10, 2017 at 12:00:43PM -0500, Waiman Long wrote:
>
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_sa
On 13 February 2017, at 19:11, Boris Ostrovsky
wrote:
>
>
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 5e5c7ae..a33f17e 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
On 02/13/2017 12:03 PM, Paul Durrant wrote:
The purpose if this ioctl is to allow a user of privcmd to restrict its
operation such that it will no longer service arbitrary hypercalls via
IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
servicing IOCTL_PRIVCMD_DM_OP.
and IOCTL
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 5e5c7ae..a33f17e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -32,6 +33,7 @@
#include
#include
#include
+#include
#i
On 02/13/2017 12:03 PM, Paul Durrant wrote:
The code sets the default return code to -ENOSYS but then overrides this
to -EINVAL in the switch() statement's default case, which is clearly
silly.
This patch removes the override and sets the default return code to
-ENOTTY, which is the convention
flight 105770 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
On 13/02/17 13:19, Jan Beulich wrote:
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setting a
> TSS limit of 255 when only 128 bytes get alloca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2017-2615 / XSA-208
version 2
oob access in cirrus bitblt copy
UPDATES IN VERSION 2
Included backport for qemu-xen versions 4.7 (and earlier)
flight 105763 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 105753
Regressions which ar
>>> On 13.02.17 at 18:01, wrote:
> On 13/02/17 16:49, Jan Beulich wrote:
> On 13.02.17 at 14:03, wrote:
>>> Sending an invalidation to the device model is an internal detail of
>>> completing the hypercall; callers should not need to be responsible for it.
>>> Drop HVM_HCALL_invalidate entire
>>> On 13.02.17 at 17:56, wrote:
On 13.02.17 at 17:32, wrote:
>> On 09/02/17 16:22, Jan Beulich wrote:
>>> Mind giving the attached patch a try (which admittedly was only
>>> lightly tested so far - in particular I haven't seen the second of
>>> the debug messages being logged, yet)?
>> Patc
The purpose if this ioctl is to allow a user of privcmd to restrict its
operation such that it will no longer service arbitrary hypercalls via
IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
servicing IOCTL_PRIVCMD_DM_OP. The aim of this is to limit the attack
surface for a compro
Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.
This patch adds IOCTL_PRIVCMD_DM_OP as gatewa
The code sets the default return code to -ENOSYS but then overrides this
to -EINVAL in the switch() statement's default case, which is clearly
silly.
This patch removes the override and sets the default return code to
-ENOTTY, which is the conventional return for an unimplemented ioctl.
Signed-of
This patch series follows on from my recent Xen series [1], to provide
support in privcmd for de-privileging of device emulators.
[1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg02558.html
Paul Durrant (3):
xen/privcmd: return -ENOTTY for unimplemented IOCTLs
xen/privcmd: Add IOC
On 13/02/17 16:49, Jan Beulich wrote:
On 13.02.17 at 14:03, wrote:
>> Sending an invalidation to the device model is an internal detail of
>> completing the hypercall; callers should not need to be responsible for it.
>> Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
>
On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote:
> Hi Tamas,
>
>
> On 13/02/17 16:20, Tamas K Lengyel wrote:
>>
>> On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
>> wrote:
>>>
>>> Hello,
>>>
>>> This e-mail is sort of follow-up to the two threads: [1] (my thread
>>> about TEE interaction)
>>> On 13.02.17 at 17:32, wrote:
> On 09/02/17 16:22, Jan Beulich wrote:
>> Mind giving the attached patch a try (which admittedly was only
>> lightly tested so far - in particular I haven't seen the second of
>> the debug messages being logged, yet)?
> Patch looks promising. I couldn't do much th
>>> On 13.02.17 at 14:03, wrote:
> Sending an invalidation to the device model is an internal detail of
> completing the hypercall; callers should not need to be responsible for it.
> Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
> appropriate.
>
> This makes the function
Hi Jan,
On 09/02/17 16:22, Jan Beulich wrote:
On 08.02.17 at 16:32, wrote:
On 07.02.17 at 18:26, wrote:
Facing a issue where bootstorm of guests leads to host crash. I debugged
and found that that enabling PML introduces a race condition during
guest teardown stage while disabling PML on
On Mon, Feb 13, 2017 at 9:29 AM, Volodymyr Babchuk
wrote:
> Tamas,
>
> On 13 February 2017 at 18:20, Tamas K Lengyel
> wrote:
>> On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
>> wrote:
>>> Hello,
>>>
>>> This e-mail is sort of follow-up to the two threads: [1] (my thread
>>> about TEE inte
flight 105771 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105771/
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
build-arm64 5 xen
>>> On 13.02.17 at 17:22, wrote:
> On 13/02/17 16:12, Andrew Cooper wrote:
>> On 13/02/17 16:01, Jan Beulich wrote:
>> On 13.02.17 at 15:32, wrote:
To avoid leaking host MSR state into guests, guest LSTAR, STAR and
SYSCALL_MASK state is unconditionally loaded when switching into gue
Tamas,
On 13 February 2017 at 18:20, Tamas K Lengyel wrote:
> On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
> wrote:
>> Hello,
>>
>> This e-mail is sort of follow-up to the two threads: [1] (my thread
>> about TEE interaction) and [2] (Edgar's thread regarding handling SMC
>> calls in platf
>>> On 13.02.17 at 17:12, wrote:
> On 13/02/17 16:01, Jan Beulich wrote:
> On 13.02.17 at 15:32, wrote:
>>> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
>>> SYSCALL_MASK state is unconditionally loaded when switching into guest
>>> context.
>>>
>>> Attempting to dirty-tr
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
wrote:
> Hello,
>
> This e-mail is sort of follow-up to the two threads: [1] (my thread
> about TEE interaction) and [2] (Edgar's thread regarding handling SMC
> calls in platform_hvc). I want to discuss more broad topic there.
>
> Obviously, ther
On 13/02/17 16:12, Andrew Cooper wrote:
> On 13/02/17 16:01, Jan Beulich wrote:
> On 13.02.17 at 15:32, wrote:
>>> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
>>> SYSCALL_MASK state is unconditionally loaded when switching into guest
>>> context.
>>>
>>> Attempting to di
Hi Roger,
On 02/02/17 15:40, Roger Pau Monné wrote:
On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
Or maybe we could avoid mapping the doorbell in the guest and let Xen
receive an SMMU abort. When receiving the SMMU abort, Xen could sanitize the
value and write into the real MSI
>>> On 13.02.17 at 14:58, wrote:
> On 13/02/17 11:40, Jan Beulich wrote:
> On 10.02.17 at 17:38, wrote:
>>> On 01/02/17 11:12, Jan Beulich wrote:
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
>>
On 13/02/17 16:01, Jan Beulich wrote:
On 13.02.17 at 15:32, wrote:
>> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
>> SYSCALL_MASK state is unconditionally loaded when switching into guest
>> context.
>>
>> Attempting to dirty-track the state is pointless; host state is
On Mon, Feb 13, 2017 at 04:04:43PM +, Andrew Cooper wrote:
> On 13/02/17 15:59, Wei Liu wrote:
> > On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> >> Sorry, I've forgot to re-generate the patch after adding the maintainers...
> >>
> >> On Mon, Feb 13, 2017 at 03:47:38PM +
On Mon, Feb 13, 2017 at 03:59:15PM +, Wei Liu wrote:
> On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> > Sorry, I've forgot to re-generate the patch after adding the maintainers...
> >
> > On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > > Bash it's not u
>>> On 13.02.17 at 15:32, wrote:
> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
> SYSCALL_MASK state is unconditionally loaded when switching into guest
> context.
>
> Attempting to dirty-track the state is pointless; host state is always
> restoring upon exit from guest con
On 13/02/17 15:59, Wei Liu wrote:
> On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
>> Sorry, I've forgot to re-generate the patch after adding the maintainers...
>>
>> On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
>>> Bash it's not used on FreeBSD.
>>>
>>> Signe
>>> On 13.02.17 at 16:56, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> Sorry, I've forgot to re-generate the patch after adding the maintainers...
>
> On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > Bash it's not used on FreeBSD.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
>
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Drop all the adjustments to MSR_CSTAR
---
xen/a
>>> On 13.02.17 at 15:32, wrote:
> A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
> moving in and out of HVM vcpu context. Two of these values are compile time
> constants, and the third is directly available in an existing per-cpu
> variable.
>
> There is no need t
>>> On 13.02.17 at 16:33, wrote:
> On 13/02/17 15:30, Jan Beulich wrote:
> On 13.02.17 at 16:26, wrote:
>>> On 13/02/17 15:19, Jan Beulich wrote:
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus.
> Introduce a
> new define a
Sorry, I've forgot to re-generate the patch after adding the maintainers...
On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> Bash it's not used on FreeBSD.
>
> Signed-off-by: Roger Pau Monné
> ---
> Please re-run autoconf after applying
> ---
> tools/configure.ac | 6 +-
>
Bash it's not used on FreeBSD.
Signed-off-by: Roger Pau Monné
---
Please re-run autoconf after applying
---
tools/configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/configure.ac b/tools/configure.ac
index 873e18d..28a539c 100644
--- a/tools/configure.ac
+
Hi Stefano,
On 10/02/17 01:01, Stefano Stabellini wrote:
On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA.
PCI DMA devs could be locked in to only be able to access this mem + MSI
doorbell.
Guests can still screw each other
On 02/02/17 15:33, Edgar E. Iglesias wrote:
On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
On 31/01/2017 19:06, Edgar E. Iglesias wrote:
On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
Thank you for the documentation. I am trying to understand if we could move
init
On 13/02/17 15:30, Jan Beulich wrote:
On 13.02.17 at 16:26, wrote:
>> On 13/02/17 15:19, Jan Beulich wrote:
>> On 13.02.17 at 15:32, wrote:
Xen's choice of the MSR_STAR value is constant across all pcpus.
Introduce a
new define and use it to avoid the opencoding in
>>> On 13.02.17 at 16:26, wrote:
> On 13/02/17 15:19, Jan Beulich wrote:
> On 13.02.17 at 15:32, wrote:
>>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce
>>> a
>>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>>> and restore_rest_
On 13/02/17 15:19, Jan Beulich wrote:
On 13.02.17 at 15:32, wrote:
>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>> and restore_rest_processor_state().
>>
>> Despite Intel hardwa
On Mon, Feb 13, 2017 at 07:50:07AM -0700, Jan Beulich wrote:
> >>> On 13.02.17 at 15:34, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> > @@ -595,9 +595,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
> > [mcheck_intel] = "Intel"
> >
On 13/02/17 15:17, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 02:40:00PM +, Andrew Cooper wrote:
>> On 13/02/17 14:34, Roger Pau Monne wrote:
>>> @@ -1706,7 +1706,7 @@ gnttab_prepare_for_transfer(
>>> if ( unlikely(ref >= nr_grant_entries(rgt)) )
>>> {
>>> gdprintk(XENL
On Mon, Feb 13, 2017 at 01:03:43PM +, Andrew Cooper wrote:
> Andrew Cooper (5):
> x86/hvm: Rework HVM_HCALL_invalidate handling
> x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c
> x86/hvm: Improve memory_op hypercall dispatching
> x86/hvm: Improve grant_table_op hyp
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
>
> Despite Intel hardware having an MSR_CSTAR register, nothing ac
On Mon, Feb 13, 2017 at 02:40:00PM +, Andrew Cooper wrote:
> On 13/02/17 14:34, Roger Pau Monne wrote:
> > Due to the large number of grants in use it seems more useful to print the
> > grant references and handlers in hex format rather than decimal.
> >
> > Signed-off-by: Roger Pau Monné
> >
On 02/13/2017 08:03 AM, Andrew Cooper wrote:
Sending an invalidation to the device model is an internal detail of
completing the hypercall; callers should not need to be responsible for it.
Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
appropriate.
This makes the funct
1 - 100 of 177 matches
Mail list logo
