[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 05/26] xen/x86: make VM_EVENT depend on CONFIG_MGMT_HYPERCALLS
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
- Date: Sat, 13 Sep 2025 19:21:11 -0400
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=tklengyel.com; spf=pass smtp.mailfrom=tamas@xxxxxxxxxxxxx; dmarc=pass header.from=<tamas@xxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1757805710; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=Lb4oPEpeznTSNONNNkvIwZWMW8wPE/TZ8ZqgB31kdBU=; b=NSoPXnzXA639TFkNgfIiRYqfiVgi7+MuoGlPp1QvxTT788pSSVOWM9HL45geL7dAj2VFITu5Je8FJvYF0D+oE5ggzpEIeQ/eXVQ29yEx+orttH6SpcUEVoPNKo8uiV+Py3pGEDuth+T2PHYyI7uOSHLblWo6OoxMzy7Gw97R114=
- Arc-seal: i=1; a=rsa-sha256; t=1757805710; cv=none; d=zohomail.com; s=zohoarc; b=Svcm3mobCYbmtaKgvDfiCw1S4czfRKrJHI7Nxwh20aCslb3hRrIkLmmtS2hnV5ddndgiz8urjqKjGSwEiWih8UM7qzknWYXaC/C+SBYtBqzENc9mZq+shimHU8EAZdgTrvXJCIULqGbP/j05yjzWSL6bYQtcgEaXpdw9Qx242Rw=
- Cc: Penny Zheng <Penny.Zheng@xxxxxxx>, ray.huang@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Sat, 13 Sep 2025 23:22:15 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Sep 10, 2025 at 11:06 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 10.09.2025 09:38, Penny Zheng wrote:
> > VM event could only be enabled/disabled via vm_event domctl-op, so
> > CONFIG_VM_EVENT shall depend on CONFIG_MGMT_HYPERCALLS
> >
> > Signed-off-by: Penny Zheng <Penny.Zheng@xxxxxxx>
>
> Looks plausible to me, so:
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> but really Tamas (now Cc-ed) should also get a chance to express possible
> concerns.
No concerns, thanks.
Tamas
|
