Hi,
On Wed, Jun 01, 2022 at 08:39:08PM +0100, Alexandru Elisei wrote:
> Hi,
>
> On Wed, Jun 01, 2022 at 05:14:00PM +0100, Andre Przywara wrote:
> > On Wed, 1 Jun 2022 15:17:50 +0100
> > Alexandru Elisei wrote:
> >
> > Hi Alex,
> >
> > > Hi,
> > >
> > > Thank you for having a look! Replies bel
Hi,
On Wed, Jun 01, 2022 at 08:39:08PM +0100, Alexandru Elisei wrote:
> Hi,
>
> On Wed, Jun 01, 2022 at 05:14:00PM +0100, Andre Przywara wrote:
> > On Wed, 1 Jun 2022 15:17:50 +0100
> > Alexandru Elisei wrote:
> >
> > Hi Alex,
> >
[..]
> > So if we care about garbage as an argument, we should
Hi,
On Wed, Jun 01, 2022 at 05:14:00PM +0100, Andre Przywara wrote:
> On Wed, 1 Jun 2022 15:17:50 +0100
> Alexandru Elisei wrote:
>
> Hi Alex,
>
> > Hi,
> >
> > Thank you for having a look! Replies below.
> >
> > On Wed, Jun 01, 2022 at 02:39:55PM +0100, Andre Przywara wrote:
> > > On Wed, 25
On Tue, May 31, 2022 at 06:01:58PM +0100, Will Deacon wrote:
> Have you spotted any pattern for when the leak occurs? How are you
> terminating the guest?
It just to send a SIGTERM to the qemu-system-aarch64 process. Origially,
right after sending the signal, it will remove_id/unbind from the vfio
On Tue, May 31, 2022 at 05:57:11PM +0100, Will Deacon wrote:
> On Thu, May 26, 2022 at 04:39:56PM -0400, Qian Cai wrote:
> > Running some SR-IOV workloads could trigger some leak reports from
> > kmemleak.
> >
> > unreferenced object 0x080243cef500 (size 128):
> > comm "qemu-system-aar", pid
On Wed, 01 Jun 2022 14:51:59 +0100,
Sasha Levin wrote:
>
> From: Ricardo Koller
>
> [ Upstream commit a1ccfd6f6e06eceb632cc29c4f15a32860f05a7e ]
>
> Restoring a corrupted collection entry (like an out of range ID) is
> being ignored and treated as success. More specifically, a
> vgic_its_resto
On Wed, 1 Jun 2022 15:17:50 +0100
Alexandru Elisei wrote:
Hi Alex,
> Hi,
>
> Thank you for having a look! Replies below.
>
> On Wed, Jun 01, 2022 at 02:39:55PM +0100, Andre Przywara wrote:
> > On Wed, 25 May 2022 12:23:41 +0100
> > Alexandru Elisei wrote:
> >
> > Hi,
> >
> > > From: Suzuk
Hi,
Thank you for having a look! Replies below.
On Wed, Jun 01, 2022 at 02:39:55PM +0100, Andre Przywara wrote:
> On Wed, 25 May 2022 12:23:41 +0100
> Alexandru Elisei wrote:
>
> Hi,
>
> > From: Suzuki K Poulose
> >
> > Allow the user to use the standard B (bytes), K (kilobytes), M (megabyte
From: Ricardo Koller
[ Upstream commit a1ccfd6f6e06eceb632cc29c4f15a32860f05a7e ]
Restoring a corrupted collection entry (like an out of range ID) is
being ignored and treated as success. More specifically, a
vgic_its_restore_cte failure is treated as success by
vgic_its_restore_collection_table
From: Ricardo Koller
[ Upstream commit a1ccfd6f6e06eceb632cc29c4f15a32860f05a7e ]
Restoring a corrupted collection entry (like an out of range ID) is
being ignored and treated as success. More specifically, a
vgic_its_restore_cte failure is treated as success by
vgic_its_restore_collection_table
On Wed, 25 May 2022 12:23:38 +0100
Alexandru Elisei wrote:
> For 64-bit guests, kvmtool exists with an error in kvm__get_vm_type() if
> the memory size is larger than what KVM supports. For 32-bit guests, the
> RAM size is silently rounded down to ARM_LOMAP_MAX_MEMORY in
> kvm__arch_init().
>
>
On Wed, 25 May 2022 12:23:42 +0100
Alexandru Elisei wrote:
> From: Julien Grall
>
> The kvm struct already contains a pointer to the configuration, which
> contains both hugetlbfs_path and ram_size, so is it not necessary to pass
> them as arguments to kvm__arch_init().
>
> Signed-off-by: Juli
On Wed, 25 May 2022 12:23:36 +0100
Alexandru Elisei wrote:
> host_ram_size() uses sysconf() to calculate the available ram, and
> sysconf() can fail. When that happens, host_ram_size() returns 0. kvmtool
> warns the user when the configured VM ram size exceeds the size of the
> host's memory, but
On Wed, 25 May 2022 12:23:43 +0100
Alexandru Elisei wrote:
Hi,
> From: Julien Grall
>
> RAM initialization is unnecessarily split between kvm__init_ram() and
> kvm__arch_init(). Move all code related to RAM initialization to
> kvm__init_ram(), making the code easier to follow and to modify.
>
On Wed, 25 May 2022 12:23:44 +0100
Alexandru Elisei wrote:
> Add a new function, kvm__arch_default_ram_address(), which returns the
> default address for guest RAM for each architecture.
>
> Signed-off-by: Alexandru Elisei
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arm/aarch32/kvm.c
On Wed, 25 May 2022 12:23:41 +0100
Alexandru Elisei wrote:
Hi,
> From: Suzuki K Poulose
>
> Allow the user to use the standard B (bytes), K (kilobytes), M (megabytes),
> G (gigabytes), T (terabytes) and P (petabytes) suffixes for memory size.
> When none are specified, the default is megabytes
On Wed, 25 May 2022 12:23:45 +0100
Alexandru Elisei wrote:
Hi,
> Allow the user to specify the RAM base address by using -m/--mem size@addr
> command line argument. The base address must be above 2GB, as to not
> overlap with the MMIO I/O region.
>
> Signed-off-by: Alexandru Elisei
> ---
> ar
On Wed, 25 May 2022 12:23:39 +0100
Alexandru Elisei wrote:
> For 32-bit guests, the maximum memory size is represented by the define
> ARM_LOMAP_MAX_MEMORY, which ARM_MAX_MEMORY() returns.
>
> For 64-bit guests, the RAM size is checked against the maximum allowed
> by KVM in kvm__get_vm_type().
On Wed, 25 May 2022 12:23:40 +0100
Alexandru Elisei wrote:
> The ARM_HIMAP_MAX_MEMORY() is a remnant of a time when KVM only supported
> 40 bits if IPA. There are no users left for this macro, remove it.
>
> Signed-off-by: Alexandru Elisei
Could be stashed together with the previous patch, I g
On Wed, 25 May 2022 12:23:34 +0100
Alexandru Elisei wrote:
Hi,
> Append ULL to all of the size definitions to make them 64bit and avoid
> overflows.
I am not fully convinced this is the best solution, as it deviates from
the kernel file, and just papers over issues at the call sites. I
acknowle
20 matches
Mail list logo
