On Thu, May 28, 2020 at 07:10:46AM +0200, Paolo Bonzini wrote:
> On 28/05/20 06:35, Yan Zhao wrote:
> > On Tue, May 26, 2020 at 10:26:35AM +0100, Peter Maydell wrote:
> >> On Mon, 25 May 2020 at 11:20, Paolo Bonzini wrote:
> >>> Not all of them, only those that need to return MEMTX_ERROR. I would
On 28/05/20 06:35, Yan Zhao wrote:
> On Tue, May 26, 2020 at 10:26:35AM +0100, Peter Maydell wrote:
>> On Mon, 25 May 2020 at 11:20, Paolo Bonzini wrote:
>>> Not all of them, only those that need to return MEMTX_ERROR. I would
>>> like some guidance from Peter as to whether (or when) reads from R
On Tue, May 26, 2020 at 10:26:35AM +0100, Peter Maydell wrote:
> On Mon, 25 May 2020 at 11:20, Paolo Bonzini wrote:
> > Not all of them, only those that need to return MEMTX_ERROR. I would
> > like some guidance from Peter as to whether (or when) reads from ROMs
> > should return MEMTX_ERROR. Th
On Mon, 25 May 2020 at 11:20, Paolo Bonzini wrote:
> Not all of them, only those that need to return MEMTX_ERROR. I would
> like some guidance from Peter as to whether (or when) reads from ROMs
> should return MEMTX_ERROR. This way, we can use that information to
> device what the read-only ram
On Tue, 26 May 2020 at 03:21, Yan Zhao wrote:
> so which regions should keep ops->write and which regions should not?
Devices which never need to return a transaction failure
and which never care about transaction attributes can
continue to use ops->write (this is most devices).
It's only if you
On Mon, May 25, 2020 at 01:04:56PM +0200, Paolo Bonzini wrote:
> On 25/05/20 12:54, Philippe Mathieu-Daudé wrote:
> >> Not all of them, only those that need to return MEMTX_ERROR. I would
> >> like some guidance from Peter as to whether (or when) reads from ROMs
> >> should return MEMTX_ERROR. Th
On 25/05/20 12:54, Philippe Mathieu-Daudé wrote:
>> Not all of them, only those that need to return MEMTX_ERROR. I would
>> like some guidance from Peter as to whether (or when) reads from ROMs
>> should return MEMTX_ERROR. This way, we can use that information to
>> device what the read-only ra
On 5/25/20 12:20 PM, Paolo Bonzini wrote:
> On 25/05/20 03:18, Yan Zhao wrote:
>> On Thu, May 21, 2020 at 04:38:47PM +0200, Paolo Bonzini wrote:
>>> On 30/04/20 11:40, Peter Maydell wrote:
> This does not "drop" a write to a r/o region -- it causes it to generate
> whatever the guest archit
On 25/05/20 03:18, Yan Zhao wrote:
> On Thu, May 21, 2020 at 04:38:47PM +0200, Paolo Bonzini wrote:
>> On 30/04/20 11:40, Peter Maydell wrote:
This does not "drop" a write to a r/o region -- it causes it to generate
whatever the guest architecture's equivalent of a bus error is (eg data
>
On Thu, May 21, 2020 at 04:38:47PM +0200, Paolo Bonzini wrote:
> On 30/04/20 11:40, Peter Maydell wrote:
> >> This does not "drop" a write to a r/o region -- it causes it to generate
> >> whatever the guest architecture's equivalent of a bus error is (eg data
> >> abort on Arm).
>
>
> > More gene
On 30/04/20 11:40, Peter Maydell wrote:
>> This does not "drop" a write to a r/o region -- it causes it to generate
>> whatever the guest architecture's equivalent of a bus error is (eg data
>> abort on Arm).
> More generally, this change seems a bit odd: currently we do not
> check the mr->reado
On Thu, Apr 30, 2020 at 05:40:25PM +0800, Peter Maydell wrote:
> On Thu, 30 Apr 2020 at 09:20, Yan Zhao wrote:
> >
> > for ram device regions, drop guest writes if the region is read-only.
> >
> > Cc: Philippe Mathieu-Daudé
> > Reviewed-by: Philippe Mathieu-Daudé
> > Signed-off-by: Yan Zhao
> >
On Thu, 30 Apr 2020 at 09:20, Yan Zhao wrote:
>
> for ram device regions, drop guest writes if the region is read-only.
>
> Cc: Philippe Mathieu-Daudé
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Yan Zhao
> Signed-off-by: Xin Zeng
> ---
> memory.c | 15 ---
> 1 file chan
for ram device regions, drop guest writes if the region is read-only.
Cc: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Yan Zhao
Signed-off-by: Xin Zeng
---
memory.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/memory.c b/mem
14 matches
Mail list logo
