qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 07/20] vfio/common: Add VFIOBitmap and (de)alloc functions


From: Joao Martins
Subject: Re: [PATCH v2 07/20] vfio/common: Add VFIOBitmap and (de)alloc functions
Date: Thu, 2 Mar 2023 13:24:14 +0000

On 27/02/2023 14:09, Cédric Le Goater wrote:
> On 2/22/23 18:49, Avihai Horon wrote:
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -320,6 +320,41 @@ const MemoryRegionOps vfio_region_ops = {
>>    * Device state interfaces
>>    */
>>   +typedef struct {
>> +    unsigned long *bitmap;
>> +    hwaddr size;
>> +    hwaddr pages;
>> +} VFIOBitmap;
>> +
>> +static VFIOBitmap *vfio_bitmap_alloc(hwaddr size)
>> +{
>> +    VFIOBitmap *vbmap = g_try_new0(VFIOBitmap, 1);
> 
> I think using g_malloc0() for the VFIOBitmap should be fine. If QEMU can
> not allocate a couple of bytes, we are in trouble anyway.
> 

OOM situations are rather unpredictable, and switching to g_malloc0 means we
will exit ungracefully in the middle of fetching dirty bitmaps. And this
function (vfio_bitmap_alloc) overall will be allocating megabytes for terabyte
guests.

It would be ok if we are initializing, but this is at runtime when we do
migration. I think we should stick with g_try_new0. exit on failure should be
reserved to failure to switch the kernel migration state whereby we are likely
to be dealing with a hardware failure and thus requires something more drastic.

        Joao



reply via email to

[Prev in Thread] Current Thread [Next in Thread]