search for: gicv4

...> > Acked-by: Marc Zyngier <marc.zyngier at arm.com> Any chance this fix (or anything with similar effects) gets applied sometime soon? I cannot use the model without using a similar workaround: http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/gicv4-wip&id=622ff1190890c0ae60d57e76a7c2f3e6fb27e25d and I suspect that other users of the same system are carrying their own version of the fix. Something in mainline would be infinitely better. Thanks, M. -- Jazz is not dead. It just smells funny...

...> > Acked-by: Marc Zyngier <marc.zyngier at arm.com> Any chance this fix (or anything with similar effects) gets applied sometime soon? I cannot use the model without using a similar workaround: http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/gicv4-wip&id=622ff1190890c0ae60d57e76a7c2f3e6fb27e25d and I suspect that other users of the same system are carrying their own version of the fix. Something in mainline would be infinitely better. Thanks, M. -- Jazz is not dead. It just smells funny...

...Zyngier <marc.zyngier at arm.com> > > Any chance this fix (or anything with similar effects) gets applied > sometime soon? I cannot use the model without using a similar > workaround: > > http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/gicv4-wip&id=622ff1190890c0ae60d57e76a7c2f3e6fb27e25d > > and I suspect that other users of the same system are carrying their own > version of the fix. Something in mainline would be infinitely better. > > Thanks, > > M. I'll merge this in the next pull. > -- >...

...emory windows. Relying on the hypervisor to handle it may be > >> unacceptable for real-time VMs. > >> > >> Jan > > > > Why? real-time != fast. I doubt you can avoid vm exits completely. > > We can, one property of Jailhouse (on x86, ARM is waiting for GICv4). > > Real-time == deterministic. And if you have such vm exits potentially in > your code path, you have them always - for worst-case analysis. One may > argue about probability in certain scenarios, but if the triggering side > is malicious, probability may become 1. > > Ja...

...here are only one or >> two memory windows. Relying on the hypervisor to handle it may be >> unacceptable for real-time VMs. >> >> Jan > > Why? real-time != fast. I doubt you can avoid vm exits completely. We can, one property of Jailhouse (on x86, ARM is waiting for GICv4). Real-time == deterministic. And if you have such vm exits potentially in your code path, you have them always - for worst-case analysis. One may argue about probability in certain scenarios, but if the triggering side is malicious, probability may become 1. Jan -- Siemens AG, Corporate Techno...

...here are only one or >> two memory windows. Relying on the hypervisor to handle it may be >> unacceptable for real-time VMs. >> >> Jan > > Why? real-time != fast. I doubt you can avoid vm exits completely. We can, one property of Jailhouse (on x86, ARM is waiting for GICv4). Real-time == deterministic. And if you have such vm exits potentially in your code path, you have them always - for worst-case analysis. One may argue about probability in certain scenarios, but if the triggering side is malicious, probability may become 1. Jan -- Siemens AG, Corporate Techno...

On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: > On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: > > > On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote: > > > > > On

On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: > On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: > > > On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote: > > > > > On

On 2015-09-01 16:34, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote: >> On 2015-09-01 11:24, Michael S. Tsirkin wrote: >>> On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote: >>>> On 2015-09-01 10:01, Michael S. Tsirkin wrote: >>>>> On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote:

On 2015-09-01 16:34, Michael S. Tsirkin wrote: > On Tue, Sep 01, 2015 at 04:09:44PM +0200, Jan Kiszka wrote: >> On 2015-09-01 11:24, Michael S. Tsirkin wrote: >>> On Tue, Sep 01, 2015 at 11:11:52AM +0200, Jan Kiszka wrote: >>>> On 2015-09-01 10:01, Michael S. Tsirkin wrote: >>>>> On Tue, Sep 01, 2015 at 09:35:21AM +0200, Jan Kiszka wrote: