On 17/05/18 01:58, lizhuoyao wrote:
> you said VGA cannot be realistically supported on ARM at the moment,then
> wrote it's ok checked with VNC.Did you experiment in x86 or arm?
What would be the point in trying an x86 box, as we both know that it
works? I checked using virtio-gpu, on an arm64 mac
Hi Jia,
On 17/05/18 07:11, Jia He wrote:
I ever met a panic under memory pressure tests(start 20 guests and run
memhog in the host).
Please avoid using "I" in the commit description and preferably stick to
an objective description.
The root cause might be what I fixed at [1]. But from arm
On systems where CTR_EL0.DIC is set, we don't need to perform
icache invalidation to guarantee that we'll fetch the right
instruction stream.
This also means that taking a permission fault to invalidate the
icache is an unnecessary overhead.
On such systems, we can safely leave the page as being
There is no need to perform cache maintenance operations when
creating the HYP page tables if we have the multiprocessing
extensions. ARMv7 mandates them with the virtualization support,
and ARMv8 just mandates them unconditionally.
Let's remove these operations.
Signed-off-by: Marc Zyngier
---
This small series makes use of features recently introduced in the
ARMv8 architecture to relax the cache maintenance operations on CPUs
that implement these features.
FWB is the most important one. It allows stage-2 to enforce the
cacheability of memory, no matter what the guest says. It also
mand
Up to ARMv8.3, the combinaison of Stage-1 and Stage-2 attributes
results in the strongest attribute of the two stages. This means
that the hypervisor has to perform quite a lot of cache maintenance
just in case the guest has some non-cacheable mappings around.
ARMv8.4 solves this problem by offer
Set/Way handling is one of the ugliest corners of KVM. We shouldn't
have to handle that, but better safe than sorry.
Thankfully, FWB fixes this for us by not requiering any maintenance
whatsoever, which means we don't have to emulate S/W CMOs, and don't
have to track VM ops either.
We still have
Hi Suzuki
On 5/17/2018 4:17 PM, Suzuki K Poulose Wrote:
>
> Hi Jia,
>
> On 17/05/18 07:11, Jia He wrote:
>> I ever met a panic under memory pressure tests(start 20 guests and run
>> memhog in the host).
>
> Please avoid using "I" in the commit description and preferably stick to
> an objective
On Wed, May 16, 2018 at 03:51:14PM +0100, James Morse wrote:
> The first two overload existing architectural behavior, the third improves all
> this with a third standard option. Its the standard story!
:-)
> I thought this was safe because its just ghes_copy_tofrom_phys()s access to
> the
> fix
On Wed, May 16, 2018 at 11:38:16AM -0400, Tyler Baicar wrote:
> I haven't seen a deadlock from that, but it looks possible. What if
> the ghes_proc() call in ghes_probe() is moved before the second switch
> statement? That way it is before the NMI/IRQ/poll is setup. At quick
> glance I think that s
On 17/05/18 13:46, Jia He wrote:
Hi Suzuki
On 5/17/2018 4:17 PM, Suzuki K Poulose Wrote:
Hi Jia,
On 17/05/18 07:11, Jia He wrote:
I ever met a panic under memory pressure tests(start 20 guests and run
memhog in the host).
Please avoid using "I" in the commit description and preferably stic
Hi Borislav,
On 17/05/18 14:36, Borislav Petkov wrote:
> On Wed, May 16, 2018 at 03:51:14PM +0100, James Morse wrote:
>> I thought this was safe because its just ghes_copy_tofrom_phys()s access to
>> the
>> fixmap slots that needs mutual exclusion.
and here is where I was wrong: I was only looki
Hi Suzuki
On 5/17/2018 11:03 PM, Suzuki K Poulose Wrote:
> On 17/05/18 13:46, Jia He wrote:
>> Hi Suzuki
>>
>> On 5/17/2018 4:17 PM, Suzuki K Poulose Wrote:
>>>
>>> Hi Jia,
>>>
>>> On 17/05/18 07:11, Jia He wrote:
I ever met a panic under memory pressure tests(start 20 guests and run
mem
13 matches
Mail list logo
