lkml.org 
[lkml]   [2024]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v5 4/5] dt-bindings: rng: Add vmgenid support
    From
    On 17/04/2024 10:12, Babis Chalios wrote:
    > From: Sudan Landge <sudanl@amazon.com>
    >
    > Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
    > ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
    > ACPI only device.
    >
    > VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
    > a mechanism for the BIOS/hypervisors to communicate to the virtual machine
    > that it is executed with a different configuration (e.g. snapshot execution
    > or creation from a template).
    > The guest operating system can use the notification for various purposes
    > such as re-initializing its random number generator etc.
    >
    > As per the specs, hypervisor should provide a globally unique identified,
    > or GUID via ACPI.
    >
    > This patch tries to mimic the mechanism to provide the same functionality
    > which is for a hypervisor/BIOS to notify the virtual machine when it is
    > executed with a different configuration.
    >
    > As part of this support the devicetree bindings requires the hypervisors or
    > BIOS to provide a memory address which holds the GUID and an IRQ which is
    > used to notify when there is a change in the GUID.
    > The memory exposed in the DT should follow the rules defined in the
    > vmgenid spec mentioned above.
    >
    > *Reason for this change*:
    > Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
    > Without going into details of why a hypervisor would chose DT over ACPI,
    > we would like to highlight that the hypervisors that have chose devicetree
    > and now want to make use of the vmgenid functionality cannot do so today
    > because vmgenid is an ACPI only device.
    > This forces these hypervisors to change their design which could have
    > undesirable impacts on their use-cases, test-scenarios etc.
    >
    > The point of vmgenid is to provide a mechanism to discover a GUID when
    > the execution state of a virtual machine changes and the simplest
    > way to do it is pass a memory location and an interrupt via devicetree.
    > It would complicate things unnecessarily if instead of using devicetree,
    > we try to implement a new protocol or modify other protocols to somehow
    > provide the same functionility.
    >
    > We believe that adding a devicetree binding for vmgenid is a simpler,
    > better alternative to provide the same functionality and will allow
    > such hypervisors as mentioned above to continue using devicetree.
    >
    > More references to vmgenid specs:
    > - https://www.qemu.org/docs/master/specs/vmgenid.html
    > - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-
    > machine-generation-identifier
    >
    > Signed-off-by: Sudan Landge <sudanl@amazon.com>

    Missing SoB. Probably everywhere...



    Best regards,
    Krzysztof


    \
     
     \ /
      Last update: 2024-04-17 15:16    [W:4.617 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site