On 2/23/23 10:51 PM, Peter Maydell wrote:
On Thu, 23 Feb 2023 at 00:52, Gavin Shan wrote:
On 2/23/23 2:54 AM, Peter Maydell wrote:
But we might have to for other boards we add later. We shouldn't
put code in per-board if it's not really board specific.
Moreover, I think "we need the backup
On Thu, 23 Feb 2023 at 00:52, Gavin Shan wrote:
>
> On 2/23/23 2:54 AM, Peter Maydell wrote:
> > But we might have to for other boards we add later. We shouldn't
> > put code in per-board if it's not really board specific.
> >
> > Moreover, I think "we need the backup bitmap if the kernel is
> >
On 2/23/23 2:54 AM, Peter Maydell wrote:
On Wed, 22 Feb 2023 at 04:36, Gavin Shan wrote:
On 2/22/23 3:27 AM, Peter Maydell wrote:
Why does this need to be board-specific code? Is there
some way we can just do the right thing automatically?
Why does the GIC/ITS matter?
The kernel should
On Wed, 22 Feb 2023 at 04:36, Gavin Shan wrote:
>
> On 2/22/23 3:27 AM, Peter Maydell wrote:
> > Why does this need to be board-specific code? Is there
> > some way we can just do the right thing automatically?
> > Why does the GIC/ITS matter?
> >
> > The kernel should already know whether we
On 2/22/23 3:27 AM, Peter Maydell wrote:
On Mon, 13 Feb 2023 at 00:40, Gavin Shan wrote:
When KVM device "kvm-arm-gicv3" or "arm-its-kvm" is used, we have to
enable the backup bitmap for the dirty ring. Otherwise, the migration
will fail because those two devices are using the backup bitmap
On Mon, 13 Feb 2023 at 00:40, Gavin Shan wrote:
>
> When KVM device "kvm-arm-gicv3" or "arm-its-kvm" is used, we have to
> enable the backup bitmap for the dirty ring. Otherwise, the migration
> will fail because those two devices are using the backup bitmap to track
> dirty guest memory,
When KVM device "kvm-arm-gicv3" or "arm-its-kvm" is used, we have to
enable the backup bitmap for the dirty ring. Otherwise, the migration
will fail because those two devices are using the backup bitmap to track
dirty guest memory, corresponding to various hardware tables.
Signed-off-by: Gavin
