All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Ani Sinha <ani@anisinha.ca>
Cc: gsomlo@gmail.com, kraxel@redhat.com, qemu-devel@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2] hw/smbios: fix memory corruption for large guests due to handle overlap
Date: Tue, 8 Feb 2022 08:48:11 +0100	[thread overview]
Message-ID: <20220208084811.0127206d@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2202072040490.2536804@anisinha-lenovo>

On Mon, 7 Feb 2022 20:42:35 +0530 (IST)
Ani Sinha <ani@anisinha.ca> wrote:

> >
> > So question is it is worth to have legacy SMBIOS code and introduce a
> > new handle layout + memory_region re-sizable SMBIOS tables like we did
> > with ACPI ones.
> >
> > That way we we will be free to change SMBIOS tables at will without a
> > risk of breaking migration and without need to add compat knob for every
> > change to keep src and dst binary compatible.
> >  
> 
> Could you please point me to the change on the acpi side so that I can
> study it and look into the refactoring for smbios side?
> 

I'd suggest to start looking at acpi_add_rom_blob() and how it evolved to
the current code. Eventually you should find a commit introducing resizable
memory_regions introduced by Michael, it I recall correctly it was around
that time when we switched ACPI tables to memory regions.



      reply	other threads:[~2022-02-08  9:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 13:09 [PATCH v2] hw/smbios: fix memory corruption for large guests due to handle overlap Ani Sinha
2022-02-04  9:34 ` Igor Mammedov
2022-02-04 11:05   ` Gerd Hoffmann
2022-02-04 12:18     ` Igor Mammedov
2022-02-04 13:52       ` Ani Sinha
2022-02-10 12:32         ` Ani Sinha
2022-02-04 13:51   ` Michael S. Tsirkin
2022-02-07 15:12   ` Ani Sinha
2022-02-08  7:48     ` Igor Mammedov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220208084811.0127206d@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ani@anisinha.ca \
    --cc=gsomlo@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.