On 09/03/2017 06:31 PM, Jan Kiszka wrote:
> On 2017-07-20 11:19, 'Nikhil Devshatwar' via Jailhouse wrote:
>> virt_id is not available when working with GIC v3
>> It needs to be properly supported later
>> For now, disable using virt_id
>>
>> Signed-off-by: Nikhil Devshatwar <[email protected]>
>> ---
>>  hypervisor/arch/arm-common/gic-v3.c | 11 ++++++++---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/hypervisor/arch/arm-common/gic-v3.c 
>> b/hypervisor/arch/arm-common/gic-v3.c
>> index 2ea947f..5f9c6e7 100644
>> --- a/hypervisor/arch/arm-common/gic-v3.c
>> +++ b/hypervisor/arch/arm-common/gic-v3.c
>> @@ -217,7 +217,8 @@ static enum mmio_result gic_handle_redist_access(void 
>> *arg,
>>       * need to translate the redistributor address.
>>       */
>>      for_each_cpu(cpu, cell->cpu_set) {
>> -            virt_id = arm_cpu_phys2virt(cpu);
>> +            //virt_id = arm_cpu_phys2virt(cpu);
>> +            virt_id = cpu;
>>              offs = per_cpu(virt_id)->gicr_base - gicr_base;
>>              if (mmio->address >= offs &&
>>                  mmio->address < offs + redist_size) {
>> @@ -235,9 +236,11 @@ static enum mmio_result gic_handle_redist_access(void 
>> *arg,
>>      if (!mmio->is_write) {
>>              switch (mmio->address) {
>>              case GICR_TYPER:
>> +#if 0
>>                      if (virt_id == cell->arch.last_virt_id)
>>                              mmio->value = GICR_TYPER_Last;
>>                      else
>> +#endif
>>                              mmio->value = 0;
> 
> This is definitely not correct, even when removing virt_id (which I'm
> planning to do, first tests look promising). Guests (at least Linux)
Apropos removing virt_id: I sent a bunch of RFC patches a couple of
weeks ago (PSCI support for arm and arm64 inmates). One patch removed
virt ids and introduced id-mapped CPU ids. I think I was just missing
GICv3 support, as I'm lacking hardware.

  Ralf
> expect to find each region terminated by GICR_TYPER_Last. So the problem
> will surface when we first use a SoC with multiple redist regions.
> 
> If we no longer virtualize the redist regions so that they are always
> consecutive from guest POV, we have to identify and mark the terminating
> ones - or declare each region non-consecutive, even if it is. The latter
> is simple but will require some more work when created device trees for
> non-root cells.
> 
> Jan
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to