Re: Re: [PATCH v2 0/2] Drop ignore_memory_transaction_failures for xilink_zynq

[Chao Liu <chao.liu@yeah.net>]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

On 2024/9/27 22:20, Peter Maydell wrote:

> On Fri, 27 Sept 2024 at 15:03, Chao Liu<chao.liu@yeah.net> wrote:
>> On 2024/9/27 20:18, Peter Maydell wrote:
>>> On Fri, 27 Sept 2024 at 09:52, Chao Liu<chao.liu@yeah.net> wrote:
>>> Even if our test set is not sufficiently comprehensive, we can create an
>>> unimp_device for the maximum address space allowed by the board. This prevents
>>> the guest system from triggering unexpected exceptions when accessing
>>> unimplemented devices or regions.
>> What would be the benefit of doing that? If we're going to
>> say "we'll make accesses to regions without devices not
>> generate faults", the simplest way to do that is to
>> leave the ignore_memory_transaction_failures flag set
>> the way it is.
>> Introducing this flag provides a straightforward way to suppress
>> memory access exceptions by checking if the flag is enabled after
>> a CPU memory access failure; however,its primary purpose is to
>> ensure compatibility.
>> Since we can designate unimplemented device memory ranges with
>> "unimplemented-device," this represents a more standard approach in QEMU
>> for managing RAZ/WI behavior.
> I don't think that using a 4GB unimplemented-device is
> a "more standard" way to do this. We have a standard way for
> the board model to say "we don't know whether there might
> be existing guest code out there that relies on being able
> to make accesses to addresses where there should be a device
> but we haven't modeled it". That way is to set the
> ignore_memory_transaction_failures flag.
>
> There are two things we can do:
>
> (1) We can leave the ignore_memory_transaction_failures
> flag set. This is safe (no behaviour change) but not the
> right (matching the hardware) behaviour. The main reason
> to do this is if we don't feel we have enough access to
> a range of guest code to test the other approach.
>
> (2) We can clear the flag. This is preferable (it matches the
> hardware). But the requirement to do this is that
>   (a) we must make the best effort we can to be sure we've
>       put unimplemented-device placeholders for specific
>       devices we don't yet model (by checking e.g. the
>       hardware documentation for the SoC and board model,
>       the device tree, etc)
>   (b) we do the most wide-ranging testing of guest code that
>       we can. This checks that we didn't miss anything in (a).
>
> I don't mind which of these we do. What I was asking in my
> comments on version one of your patch was for how we were
> doing on requirement 2b.
>
> thanks
> -- PMM

I understand! I will provide more comprehensive testing methods
and results as soon as possible and will get back to you.

Best regards,
Chao Liu

[-- Attachment #2: Type: text/html, Size: 3659 bytes --]