>>> On 11.12.17 at 21:26, wrote:
> On 12/11/2017 10:06 AM, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m
On 12/11/2017 11:10 AM, Andre Przywara wrote:
Hi,
Hi Andre,
But on the other hand we had PoD naturally already in KVM, so this came
at no cost.
So I believe it would be worth to investigate what the actual impact is
on booting a 32-bit kernel, with emulating s/w ops like KVM does (see
below),
Hi Jan,
On 12/11/2017 10:06 AM, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the
Hi,
On 12/10/2017 03:22 PM, Tim Deegan wrote:
At 14:38 + on 08 Dec (1512743913), Julien Grall wrote:
On 08/12/17 08:03, Tim Deegan wrote:
+1 for avoiding the full majesty of PoD if you don't need it.
It should be possible to do something like the misconfigured-entry bit
trick by _allocati
>>> On 08.12.17 at 15:38, wrote:
> On 08/12/17 08:03, Tim Deegan wrote:
>> It should be possible to do something like the misconfigured-entry bit
>> trick by _allocating_ the memory up-front and building the p2m entries
>> but only making them usable by the {IO}MMUs on first access. That
>> would
On 12/11/2017 11:10 AM, Andre Przywara wrote:
> Hi,
>
> On 08/12/17 10:56, George Dunlap wrote:
>> On 12/07/2017 07:21 PM, Marc Zyngier wrote:
>>> On 07/12/17 18:06, George Dunlap wrote:
On 12/07/2017 04:58 PM, Marc Zyngier wrote:
> On 07/12/17 16:44, George Dunlap wrote:
>> On 12/07/
On 11/12/17 10:06, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
>> On 08/12/17 08:03, Tim Deegan wrote:
>>> It should be possible to do something like the misconfigured-entry bit
>>> trick by _allocating_ the memory up-front and building the p2m entries
>>> but only making them usable by t
Hi,
On 08/12/17 10:56, George Dunlap wrote:
> On 12/07/2017 07:21 PM, Marc Zyngier wrote:
>> On 07/12/17 18:06, George Dunlap wrote:
>>> On 12/07/2017 04:58 PM, Marc Zyngier wrote:
On 07/12/17 16:44, George Dunlap wrote:
> On 12/07/2017 04:04 PM, Julien Grall wrote:
>> Hi Jan,
>>
>>> On 11.12.17 at 12:11, wrote:
> On 11/12/17 10:06, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entr
At 14:38 + on 08 Dec (1512743913), Julien Grall wrote:
> On 08/12/17 08:03, Tim Deegan wrote:
> > +1 for avoiding the full majesty of PoD if you don't need it.
> >
> > It should be possible to do something like the misconfigured-entry bit
> > trick by _allocating_ the memory up-front and build
On 08/12/17 08:03, Tim Deegan wrote:
Hi,
Hi Tim,
Somehow your e-mail was marked as spam by gmail.
At 12:58 + on 06 Dec (1512565090), Julien Grall wrote:
On 12/06/2017 12:28 PM, George Dunlap wrote:
2. It sounds like rather than using PoD, you could use the
"misconfigured p2m table" tec
On 12/07/2017 07:21 PM, Marc Zyngier wrote:
> On 07/12/17 18:06, George Dunlap wrote:
>> On 12/07/2017 04:58 PM, Marc Zyngier wrote:
>>> On 07/12/17 16:44, George Dunlap wrote:
On 12/07/2017 04:04 PM, Julien Grall wrote:
> Hi Jan,
>
> On 07/12/17 15:45, Jan Beulich wrote:
>
Hi,
At 12:58 + on 06 Dec (1512565090), Julien Grall wrote:
> On 12/06/2017 12:28 PM, George Dunlap wrote:
> > 2. It sounds like rather than using PoD, you could use the
> > "misconfigured p2m table" technique that x86 uses: set bits in the p2m
> > entry which cause a specific kind of HAP fault
On 07/12/17 18:06, George Dunlap wrote:
> On 12/07/2017 04:58 PM, Marc Zyngier wrote:
>> On 07/12/17 16:44, George Dunlap wrote:
>>> On 12/07/2017 04:04 PM, Julien Grall wrote:
Hi Jan,
On 07/12/17 15:45, Jan Beulich wrote:
On 07.12.17 at 15:53, wrote:
>> On 07/12/17 13:
On 12/07/2017 04:58 PM, Marc Zyngier wrote:
> On 07/12/17 16:44, George Dunlap wrote:
>> On 12/07/2017 04:04 PM, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 07/12/17 15:45, Jan Beulich wrote:
>>> On 07.12.17 at 15:53, wrote:
> On 07/12/17 13:52, Julien Grall wrote:
> There is exactly on
On 07/12/17 16:44, George Dunlap wrote:
> On 12/07/2017 04:04 PM, Julien Grall wrote:
>> Hi Jan,
>>
>> On 07/12/17 15:45, Jan Beulich wrote:
>> On 07.12.17 at 15:53, wrote:
On 07/12/17 13:52, Julien Grall wrote:
There is exactly one case where set/way makes sense, and that's when
>>>
On 12/07/2017 04:04 PM, Julien Grall wrote:
> Hi Jan,
>
> On 07/12/17 15:45, Jan Beulich wrote:
> On 07.12.17 at 15:53, wrote:
>>> On 07/12/17 13:52, Julien Grall wrote:
>>> There is exactly one case where set/way makes sense, and that's when
>>> you're the only CPU left in the system, your M
On 07/12/17 15:45, Jan Beulich wrote:
On 07.12.17 at 15:53, wrote:
>> On 07/12/17 13:52, Julien Grall wrote:
>> There is exactly one case where set/way makes sense, and that's when
>> you're the only CPU left in the system, your MMU is off, and you're
>> about to go down.
>
> With this and .
Hi Jan,
On 07/12/17 15:45, Jan Beulich wrote:
On 07.12.17 at 15:53, wrote:
On 07/12/17 13:52, Julien Grall wrote:
There is exactly one case where set/way makes sense, and that's when
you're the only CPU left in the system, your MMU is off, and you're
about to go down.
With this and ...
On
>>> On 07.12.17 at 16:22, wrote:
> On 07/12/17 09:39, Jan Beulich wrote:
> On 06.12.17 at 18:52, wrote:
>>> But I think this is bringing another class of problem. When a
>>> misconfigured is accessed, we would need to clean & invalidate the cache
>>> for that region.
>>
>> Why? (Please remem
>>> On 07.12.17 at 15:53, wrote:
> On 07/12/17 13:52, Julien Grall wrote:
> There is exactly one case where set/way makes sense, and that's when
> you're the only CPU left in the system, your MMU is off, and you're
> about to go down.
With this and ...
> On top of bypassing the coherency, S/W CM
(+ Marc)
@Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
me if I am wrong.
On 07/12/17 09:39, Jan Beulich wrote:
On 06.12.17 at 18:52, wrote:
On 12/06/2017 03:15 PM, Jan Beulich wrote:
What we do in x86 is that we flag all entries at the top level as
misconfigured a
On 07/12/17 13:52, Julien Grall wrote:
> (+ Marc)
>
> Hi,
>
> @Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
> me if I am wrong.
>
> Before answering to the rest of the e-mail, let me reinforce what I said
> in my first e-mail. Set/Way are very complex to emulate and a
>>> On 07.12.17 at 14:52, wrote:
> On 06/12/17 17:49, George Dunlap wrote:
>> Do you want to reset the p2m multiple times? I thought the goal was
>> simply to keep the amount of p2m space you need to flush to a minimum;
>> if you expect the memory which has been faulted in by the *last* flush
>>
(+ Marc)
Hi,
@Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
me if I am wrong.
Before answering to the rest of the e-mail, let me reinforce what I said
in my first e-mail. Set/Way are very complex to emulate and an OS using
them should never expect good performance i
>>> On 06.12.17 at 18:52, wrote:
> On 12/06/2017 03:15 PM, Jan Beulich wrote:
>> What we do in x86 is that we flag all entries at the top level as
>> misconfigured at any time where otherwise we would have to
>> walk the full tree. Upon access, the misconfigured flag is being
>> propagated down th
Hi Jan,
On 12/06/2017 03:15 PM, Jan Beulich wrote:
On 06.12.17 at 13:58, wrote:
On 12/06/2017 12:28 PM, George Dunlap wrote:
2. It sounds like rather than using PoD, you could use the
"misconfigured p2m table" technique that x86 uses: set bits in the p2m
entry which cause a specific kind of H
On 12/06/2017 12:58 PM, Julien Grall wrote:
> Hi George,
>
> On 12/06/2017 12:28 PM, George Dunlap wrote:
>> On 12/05/2017 06:39 PM, Julien Grall wrote:
>>> Hi all,
>>>
>>> Even though it is an Arm failure, I have CCed x86 folks to get feedback
>>> on the approach. I have a WIP branch I could shar
On 12/06/2017 03:24 PM, George Dunlap wrote:
On 12/06/2017 03:19 PM, Julien Grall wrote:
Hi Konrad,
On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
.snip..
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to
det
On 12/06/2017 03:19 PM, Julien Grall wrote:
> Hi Konrad,
>
> On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
>> .snip..
>>> The suggested policy is based on the KVM one:
>>> - If we trap a S/W instructions, we enable VM trapping (e.g
>>> HCR_EL2.TVM) to
>>> detect cache being turned on/of
Hi Konrad,
On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote:
.snip..
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to
detect cache being turned on/off, and do a full clean.
- We flush the caches on both
>>> On 06.12.17 at 13:58, wrote:
> On 12/06/2017 12:28 PM, George Dunlap wrote:
>> 2. It sounds like rather than using PoD, you could use the
>> "misconfigured p2m table" technique that x86 uses: set bits in the p2m
>> entry which cause a specific kind of HAP fault when accessed. The fault
>> han
.snip..
> The suggested policy is based on the KVM one:
> - If we trap a S/W instructions, we enable VM trapping (e.g
> HCR_EL2.TVM) to
> detect cache being turned on/off, and do a full clean.
> - We flush the caches on both caches being turned on and off.
> - Once the caches are
On 12/06/2017 12:58 PM, Julien Grall wrote:
Hi George,
On 12/06/2017 12:28 PM, George Dunlap wrote:
On 12/05/2017 06:39 PM, Julien Grall wrote:
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback
on the approach. I have a WIP branch I could share if that interest
Hi George,
On 12/06/2017 12:28 PM, George Dunlap wrote:
On 12/05/2017 06:39 PM, Julien Grall wrote:
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback
on the approach. I have a WIP branch I could share if that interest people.
Few months ago, we noticed an heisenb
On 12/05/2017 06:39 PM, Julien Grall wrote:
> Hi all,
>
> Even though it is an Arm failure, I have CCed x86 folks to get feedback
> on the approach. I have a WIP branch I could share if that interest people.
>
> Few months ago, we noticed an heisenbug on jobs run by osstest on the
> cubietrucks (
Hi Jan,
On 12/06/2017 09:15 AM, Jan Beulich wrote:
On 05.12.17 at 19:39, wrote:
The suggested policy is based on the KVM one:
- If we trap a S/W instructions, we enable VM trapping (e.g
HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
- We flush the caches
>>> On 05.12.17 at 19:39, wrote:
> The suggested policy is based on the KVM one:
> - If we trap a S/W instructions, we enable VM trapping (e.g
> HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
> - We flush the caches on both caches being turned on and off.
>
On 05/12/2017 22:35, Stefano Stabellini wrote:
On Tue, 5 Dec 2017, Julien Grall wrote:
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback on the
approach. I have a WIP branch I could share if that interest people.
Few months ago, we noticed an heisenbug on jobs r
On Tue, 5 Dec 2017, Julien Grall wrote:
> Hi all,
>
> Even though it is an Arm failure, I have CCed x86 folks to get feedback on the
> approach. I have a WIP branch I could share if that interest people.
>
> Few months ago, we noticed an heisenbug on jobs run by osstest on the
> cubietrucks (see
Hi all,
Even though it is an Arm failure, I have CCed x86 folks to get feedback
on the approach. I have a WIP branch I could share if that interest people.
Few months ago, we noticed an heisenbug on jobs run by osstest on the
cubietrucks (see [1]). From the log, we figured out that the guest
41 matches
Mail list logo