| Message ID | 20200403142308.82990-6-arilou@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | hyperv: VMBus implementation | expand |
Hi Jon, On 03.04.2020 16:23, Jon Doron wrote: > Guest OS uses ACPI to discover vmbus presence. Add a corresponding > entry to DSDT in case vmbus has been enabled. > > Experimentally Windows guests were found to require this entry to > include two IRQ resources, so this patch adds two semi-arbitrarily > chosen ones (7 and 13). This results, in particular, in parallel port > conflicting with vmbus. > > TODO: discover and use spare IRQs to avoid conflicts. > > Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > Signed-off-by: Jon Doron <arilou@gmail.com> Nice work, thanks! However, it seems to be based on the code version that was posted in February 2018, and not the latest version in OpenVZ qemu repository dated October 2019: https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus This newer version has slightly different API here and there. Any particular reason for selecting that older version for porting? I have actually rebased this latest version on the top of the current QEMU master, and it basically seems to work fine. However, I haven't done extensive tests whether there isn't a memory leak somewhere or so on. Maciej
Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me which was this: https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm Do you think you have a more recent version I dont mind diffing and resubmitting a new version of the patchset? Thanks, -- Jon. On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote: > > Hi Jon, > > On 03.04.2020 16:23, Jon Doron wrote: > > Guest OS uses ACPI to discover vmbus presence. Add a corresponding > > entry to DSDT in case vmbus has been enabled. > > > > Experimentally Windows guests were found to require this entry to > > include two IRQ resources, so this patch adds two semi-arbitrarily > > chosen ones (7 and 13). This results, in particular, in parallel port > > conflicting with vmbus. > > > > TODO: discover and use spare IRQs to avoid conflicts. > > > > Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > > Signed-off-by: Jon Doron <arilou@gmail.com> > > Nice work, thanks! > > However, it seems to be based on the code version that was posted in > February 2018, and not the latest version in OpenVZ qemu repository > dated October 2019: > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > > This newer version has slightly different API here and there. > Any particular reason for selecting that older version for porting? > > I have actually rebased this latest version on the top of the current > QEMU master, and it basically seems to work fine. > However, I haven't done extensive tests whether there isn't a memory leak > somewhere or so on. > > Maciej
Thank you Maciej it seems like your version is really ahead I'll do the required work and merge it so i can submit a v2 with the latest patchset from Roman On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: > > Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me > which was this: > https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm > > Do you think you have a more recent version I dont mind diffing and > resubmitting a new version of the patchset? > > Thanks, > -- Jon. > > On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero > <mail@maciej.szmigiero.name> wrote: > > > > Hi Jon, > > > > On 03.04.2020 16:23, Jon Doron wrote: > > > Guest OS uses ACPI to discover vmbus presence. Add a corresponding > > > entry to DSDT in case vmbus has been enabled. > > > > > > Experimentally Windows guests were found to require this entry to > > > include two IRQ resources, so this patch adds two semi-arbitrarily > > > chosen ones (7 and 13). This results, in particular, in parallel port > > > conflicting with vmbus. > > > > > > TODO: discover and use spare IRQs to avoid conflicts. > > > > > > Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > > > Signed-off-by: Jon Doron <arilou@gmail.com> > > > > Nice work, thanks! > > > > However, it seems to be based on the code version that was posted in > > February 2018, and not the latest version in OpenVZ qemu repository > > dated October 2019: > > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > > > > This newer version has slightly different API here and there. > > Any particular reason for selecting that older version for porting? > > > > I have actually rebased this latest version on the top of the current > > QEMU master, and it basically seems to work fine. > > However, I haven't done extensive tests whether there isn't a memory leak > > somewhere or so on. > > > > Maciej
Thanks Jon, I will push out to what I have in a moment. Maciej On 03.04.2020 17:30, Jon Doron wrote: > Thank you Maciej it seems like your version is really ahead I'll do > the required work and merge it so i can submit a v2 with the latest > patchset from Roman > > On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: >> >> Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me >> which was this: >> https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm >> >> Do you think you have a more recent version I dont mind diffing and >> resubmitting a new version of the patchset? >> >> Thanks, >> -- Jon. >> >> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero >> <mail@maciej.szmigiero.name> wrote: >>> >>> Hi Jon, >>> >>> On 03.04.2020 16:23, Jon Doron wrote: >>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding >>>> entry to DSDT in case vmbus has been enabled. >>>> >>>> Experimentally Windows guests were found to require this entry to >>>> include two IRQ resources, so this patch adds two semi-arbitrarily >>>> chosen ones (7 and 13). This results, in particular, in parallel port >>>> conflicting with vmbus. >>>> >>>> TODO: discover and use spare IRQs to avoid conflicts. >>>> >>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> >>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> >>>> Signed-off-by: Jon Doron <arilou@gmail.com> >>> >>> Nice work, thanks! >>> >>> However, it seems to be based on the code version that was posted in >>> February 2018, and not the latest version in OpenVZ qemu repository >>> dated October 2019: >>> https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >>> >>> This newer version has slightly different API here and there. >>> Any particular reason for selecting that older version for porting? >>> >>> I have actually rebased this latest version on the top of the current >>> QEMU master, and it basically seems to work fine. >>> However, I haven't done extensive tests whether there isn't a memory leak >>> somewhere or so on. >>> >>> Maciej
Hi Jon, The patches are available here: https://github.com/maciejsszmigiero/qemu.git in "vmbus-patches" branch. Please note that these patches don't have Roman's "Signed-off-by:" tags, so I haven't applied mine, either. If you are able to establish a proper SoB chain then please also add: "Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>". Thanks for the effort, Maciej On 03.04.2020 17:30, Jon Doron wrote: > Thank you Maciej it seems like your version is really ahead I'll do > the required work and merge it so i can submit a v2 with the latest > patchset from Roman > > On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: >> >> Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me >> which was this: >> https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm >> >> Do you think you have a more recent version I dont mind diffing and >> resubmitting a new version of the patchset? >> >> Thanks, >> -- Jon. >> >> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero >> <mail@maciej.szmigiero.name> wrote: >>> >>> Hi Jon, >>> >>> On 03.04.2020 16:23, Jon Doron wrote: >>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding >>>> entry to DSDT in case vmbus has been enabled. >>>> >>>> Experimentally Windows guests were found to require this entry to >>>> include two IRQ resources, so this patch adds two semi-arbitrarily >>>> chosen ones (7 and 13). This results, in particular, in parallel port >>>> conflicting with vmbus. >>>> >>>> TODO: discover and use spare IRQs to avoid conflicts. >>>> >>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> >>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> >>>> Signed-off-by: Jon Doron <arilou@gmail.com> >>> >>> Nice work, thanks! >>> >>> However, it seems to be based on the code version that was posted in >>> February 2018, and not the latest version in OpenVZ qemu repository >>> dated October 2019: >>> https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >>> >>> This newer version has slightly different API here and there. >>> Any particular reason for selecting that older version for porting? >>> >>> I have actually rebased this latest version on the top of the current >>> QEMU master, and it basically seems to work fine. >>> However, I haven't done extensive tests whether there isn't a memory leak >>> somewhere or so on. >>> >>> Maciej
It seems to me that Roman might not be getting our e-mails since his new e-mail address seems to be "rvkagan@yandex-team.ru". @Roman, are you with us? Thanks, Maciej On 03.04.2020 19:18, Maciej S. Szmigiero wrote: > Hi Jon, > > The patches are available here: > https://github.com/maciejsszmigiero/qemu.git in "vmbus-patches" branch. > > Please note that these patches don't have Roman's "Signed-off-by:" tags, > so I haven't applied mine, either. > > If you are able to establish a proper SoB chain then please also add: > "Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>". > > Thanks for the effort, > Maciej > > On 03.04.2020 17:30, Jon Doron wrote: >> Thank you Maciej it seems like your version is really ahead I'll do >> the required work and merge it so i can submit a v2 with the latest >> patchset from Roman >> >> On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: >>> >>> Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me >>> which was this: >>> https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm >>> >>> Do you think you have a more recent version I dont mind diffing and >>> resubmitting a new version of the patchset? >>> >>> Thanks, >>> -- Jon. >>> >>> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero >>> <mail@maciej.szmigiero.name> wrote: >>>> >>>> Hi Jon, >>>> >>>> On 03.04.2020 16:23, Jon Doron wrote: >>>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding >>>>> entry to DSDT in case vmbus has been enabled. >>>>> >>>>> Experimentally Windows guests were found to require this entry to >>>>> include two IRQ resources, so this patch adds two semi-arbitrarily >>>>> chosen ones (7 and 13). This results, in particular, in parallel port >>>>> conflicting with vmbus. >>>>> >>>>> TODO: discover and use spare IRQs to avoid conflicts. >>>>> >>>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> >>>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> >>>>> Signed-off-by: Jon Doron <arilou@gmail.com> >>>> >>>> Nice work, thanks! >>>> >>>> However, it seems to be based on the code version that was posted in >>>> February 2018, and not the latest version in OpenVZ qemu repository >>>> dated October 2019: >>>> https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >>>> >>>> This newer version has slightly different API here and there. >>>> Any particular reason for selecting that older version for porting? >>>> >>>> I have actually rebased this latest version on the top of the current >>>> QEMU master, and it basically seems to work fine. >>>> However, I haven't done extensive tests whether there isn't a memory leak >>>> somewhere or so on. >>>> >>>> Maciej >
On Fri, Apr 03, 2020 at 11:00:27PM +0200, Maciej S. Szmigiero wrote: > It seems to me that Roman might not be getting our e-mails since his > new e-mail address seems to be "rvkagan@yandex-team.ru". Indeed. I'm subscribed with my new address to qemu-devel ML but must have missed this series. > @Roman, are you with us? Yes ;) So what are your plans regarding this patchset? Thanks, Roman. > On 03.04.2020 19:18, Maciej S. Szmigiero wrote: > > Hi Jon, > > > > The patches are available here: > > https://github.com/maciejsszmigiero/qemu.git in "vmbus-patches" branch. > > > > Please note that these patches don't have Roman's "Signed-off-by:" tags, > > so I haven't applied mine, either. > > > > If you are able to establish a proper SoB chain then please also add: > > "Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>". > > > > Thanks for the effort, > > Maciej > > > > On 03.04.2020 17:30, Jon Doron wrote: > >> Thank you Maciej it seems like your version is really ahead I'll do > >> the required work and merge it so i can submit a v2 with the latest > >> patchset from Roman > >> > >> On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: > >>> > >>> Thank you Maciej, I based it on top of what Denis (den@openvz.org) gave me > >>> which was this: > >>> https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm > >>> > >>> Do you think you have a more recent version I dont mind diffing and > >>> resubmitting a new version of the patchset? > >>> > >>> Thanks, > >>> -- Jon. > >>> > >>> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero > >>> <mail@maciej.szmigiero.name> wrote: > >>>> > >>>> Hi Jon, > >>>> > >>>> On 03.04.2020 16:23, Jon Doron wrote: > >>>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding > >>>>> entry to DSDT in case vmbus has been enabled. > >>>>> > >>>>> Experimentally Windows guests were found to require this entry to > >>>>> include two IRQ resources, so this patch adds two semi-arbitrarily > >>>>> chosen ones (7 and 13). This results, in particular, in parallel port > >>>>> conflicting with vmbus. > >>>>> > >>>>> TODO: discover and use spare IRQs to avoid conflicts. > >>>>> > >>>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > >>>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > >>>>> Signed-off-by: Jon Doron <arilou@gmail.com> > >>>> > >>>> Nice work, thanks! > >>>> > >>>> However, it seems to be based on the code version that was posted in > >>>> February 2018, and not the latest version in OpenVZ qemu repository > >>>> dated October 2019: > >>>> https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > >>>> > >>>> This newer version has slightly different API here and there. > >>>> Any particular reason for selecting that older version for porting? > >>>> > >>>> I have actually rebased this latest version on the top of the current > >>>> QEMU master, and it basically seems to work fine. > >>>> However, I haven't done extensive tests whether there isn't a memory leak > >>>> somewhere or so on. > >>>> > >>>> Maciej > > >
Well I want it to be merged in :-) On Mon, Apr 6, 2020, 10:32 Roman Kagan <rvkagan@yandex-team.ru> wrote: > On Fri, Apr 03, 2020 at 11:00:27PM +0200, Maciej S. Szmigiero wrote: > > It seems to me that Roman might not be getting our e-mails since his > > new e-mail address seems to be "rvkagan@yandex-team.ru". > > Indeed. I'm subscribed with my new address to qemu-devel ML but must > have missed this series. > > > @Roman, are you with us? > > Yes ;) > > So what are your plans regarding this patchset? > > Thanks, > Roman. > > > On 03.04.2020 19:18, Maciej S. Szmigiero wrote: > > > Hi Jon, > > > > > > The patches are available here: > > > https://github.com/maciejsszmigiero/qemu.git in "vmbus-patches" > branch. > > > > > > Please note that these patches don't have Roman's "Signed-off-by:" > tags, > > > so I haven't applied mine, either. > > > > > > If you are able to establish a proper SoB chain then please also add: > > > "Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>". > > > > > > Thanks for the effort, > > > Maciej > > > > > > On 03.04.2020 17:30, Jon Doron wrote: > > >> Thank you Maciej it seems like your version is really ahead I'll do > > >> the required work and merge it so i can submit a v2 with the latest > > >> patchset from Roman > > >> > > >> On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: > > >>> > > >>> Thank you Maciej, I based it on top of what Denis (den@openvz.org) > gave me > > >>> which was this: > > >>> > https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm > > >>> > > >>> Do you think you have a more recent version I dont mind diffing and > > >>> resubmitting a new version of the patchset? > > >>> > > >>> Thanks, > > >>> -- Jon. > > >>> > > >>> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero > > >>> <mail@maciej.szmigiero.name> wrote: > > >>>> > > >>>> Hi Jon, > > >>>> > > >>>> On 03.04.2020 16:23, Jon Doron wrote: > > >>>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding > > >>>>> entry to DSDT in case vmbus has been enabled. > > >>>>> > > >>>>> Experimentally Windows guests were found to require this entry to > > >>>>> include two IRQ resources, so this patch adds two semi-arbitrarily > > >>>>> chosen ones (7 and 13). This results, in particular, in parallel > port > > >>>>> conflicting with vmbus. > > >>>>> > > >>>>> TODO: discover and use spare IRQs to avoid conflicts. > > >>>>> > > >>>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > > >>>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > > >>>>> Signed-off-by: Jon Doron <arilou@gmail.com> > > >>>> > > >>>> Nice work, thanks! > > >>>> > > >>>> However, it seems to be based on the code version that was posted in > > >>>> February 2018, and not the latest version in OpenVZ qemu repository > > >>>> dated October 2019: > > >>>> > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > > >>>> > > >>>> This newer version has slightly different API here and there. > > >>>> Any particular reason for selecting that older version for porting? > > >>>> > > >>>> I have actually rebased this latest version on the top of the > current > > >>>> QEMU master, and it basically seems to work fine. > > >>>> However, I haven't done extensive tests whether there isn't a > memory leak > > >>>> somewhere or so on. > > >>>> > > >>>> Maciej > > > > > >
On Fri, 3 Apr 2020 17:23:08 +0300 Jon Doron <arilou@gmail.com> wrote: > Guest OS uses ACPI to discover vmbus presence. Add a corresponding > entry to DSDT in case vmbus has been enabled. > > Experimentally Windows guests were found to require this entry to > include two IRQ resources, so this patch adds two semi-arbitrarily > chosen ones (7 and 13). This results, in particular, in parallel port > conflicting with vmbus. > > TODO: discover and use spare IRQs to avoid conflicts. CCing Vitaly as he might know whom to ping wrt 'spec' that describes vmbus and confirm with ACPI tables that native hyperv generates. > Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > Signed-off-by: Jon Doron <arilou@gmail.com> > --- > hw/i386/acpi-build.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index 2a7e55bae7..6d7fdbbe9b 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -43,6 +43,7 @@ > #include "hw/acpi/tpm.h" > #include "hw/acpi/vmgenid.h" > #include "hw/boards.h" > +#include "hw/vmbus/vmbus.h" > #include "sysemu/tpm_backend.h" > #include "hw/rtc/mc146818rtc_regs.h" > #include "migration/vmstate.h" > @@ -1270,6 +1271,43 @@ static Aml *build_com_device_aml(uint8_t uid) > return dev; > } > > +static Aml *build_vmbus_device_aml(void) > +{ > + Aml *dev; > + Aml *method; > + Aml *crs; > + > + dev = aml_device("VMBS"); > + aml_append(dev, aml_name_decl("STA", aml_int(0xF))); > + aml_append(dev, aml_name_decl("_HID", aml_string("VMBus"))); > + aml_append(dev, aml_name_decl("_UID", aml_int(0x0))); > + aml_append(dev, aml_name_decl("_DDN", aml_string("VMBUS"))); > + > + method = aml_method("_DIS", 0, AML_NOTSERIALIZED); > + aml_append(method, aml_store(aml_and(aml_name("STA"), aml_int(0xD), NULL), > + aml_name("STA"))); > + aml_append(dev, method); > + > + method = aml_method("_PS0", 0, AML_NOTSERIALIZED); > + aml_append(method, aml_store(aml_or(aml_name("STA"), aml_int(0xF), NULL), > + aml_name("STA"))); > + aml_append(dev, method); > + > + method = aml_method("_STA", 0, AML_NOTSERIALIZED); > + aml_append(method, aml_store(aml_name("STA"), aml_local(0))); > + aml_append(method, aml_return(aml_local(0))); > + aml_append(dev, method); does it need all that complicated _STA handling? Would simple aml_append(dev, aml_name_decl("_STA", aml_int(0xF))); work for you? > + aml_append(dev, aml_name_decl("_PS3", aml_int(0x0))); > + > + crs = aml_resource_template(); > + aml_append(crs, aml_irq_no_flags(7)); > + aml_append(crs, aml_irq_no_flags(13)); > + aml_append(dev, aml_name_decl("_CRS", crs)); > + > + return dev; > +} > + > static void build_isa_devices_aml(Aml *table) > { > ISADevice *fdc = pc_find_fdc0(); > @@ -1296,6 +1334,10 @@ static void build_isa_devices_aml(Aml *table) > build_acpi_ipmi_devices(scope, BUS(obj), "\\_SB.PCI0.ISA"); > } > > + if (vmbus_exists()) { > + aml_append(scope, build_vmbus_device_aml()); > + } > + > aml_append(table, scope); > } >
On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: > Well I want it to be merged in :-) Hmm I'm curious why, it has little to offer over virtio. Anyway the series you've posted seems to be based on a fairly old version. The one in openvz repo is more recent. It's still in need for improvement, too, but should be testable at least. Thanks, Roman. > On Mon, Apr 6, 2020, 10:32 Roman Kagan <rvkagan@yandex-team.ru> wrote: > > > On Fri, Apr 03, 2020 at 11:00:27PM +0200, Maciej S. Szmigiero wrote: > > > It seems to me that Roman might not be getting our e-mails since his > > > new e-mail address seems to be "rvkagan@yandex-team.ru". > > > > Indeed. I'm subscribed with my new address to qemu-devel ML but must > > have missed this series. > > > > > @Roman, are you with us? > > > > Yes ;) > > > > So what are your plans regarding this patchset? > > > > Thanks, > > Roman. > > > > > On 03.04.2020 19:18, Maciej S. Szmigiero wrote: > > > > Hi Jon, > > > > > > > > The patches are available here: > > > > https://github.com/maciejsszmigiero/qemu.git in "vmbus-patches" > > branch. > > > > > > > > Please note that these patches don't have Roman's "Signed-off-by:" > > tags, > > > > so I haven't applied mine, either. > > > > > > > > If you are able to establish a proper SoB chain then please also add: > > > > "Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>". > > > > > > > > Thanks for the effort, > > > > Maciej > > > > > > > > On 03.04.2020 17:30, Jon Doron wrote: > > > >> Thank you Maciej it seems like your version is really ahead I'll do > > > >> the required work and merge it so i can submit a v2 with the latest > > > >> patchset from Roman > > > >> > > > >> On Fri, Apr 3, 2020 at 6:06 PM Jon Doron <arilou@gmail.com> wrote: > > > >>> > > > >>> Thank you Maciej, I based it on top of what Denis (den@openvz.org) > > gave me > > > >>> which was this: > > > >>> > > https://ftp.openvz.org/virtuozzo/releases/openvz-7.0.12-288/source/SRPMS/q/qemu-kvm-vz-2.12.0-33.vz7.14.4.src.rpm > > > >>> > > > >>> Do you think you have a more recent version I dont mind diffing and > > > >>> resubmitting a new version of the patchset? > > > >>> > > > >>> Thanks, > > > >>> -- Jon. > > > >>> > > > >>> On Fri, Apr 3, 2020 at 5:56 PM Maciej S. Szmigiero > > > >>> <mail@maciej.szmigiero.name> wrote: > > > >>>> > > > >>>> Hi Jon, > > > >>>> > > > >>>> On 03.04.2020 16:23, Jon Doron wrote: > > > >>>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding > > > >>>>> entry to DSDT in case vmbus has been enabled. > > > >>>>> > > > >>>>> Experimentally Windows guests were found to require this entry to > > > >>>>> include two IRQ resources, so this patch adds two semi-arbitrarily > > > >>>>> chosen ones (7 and 13). This results, in particular, in parallel > > port > > > >>>>> conflicting with vmbus. > > > >>>>> > > > >>>>> TODO: discover and use spare IRQs to avoid conflicts. > > > >>>>> > > > >>>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> > > > >>>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > > > >>>>> Signed-off-by: Jon Doron <arilou@gmail.com> > > > >>>> > > > >>>> Nice work, thanks! > > > >>>> > > > >>>> However, it seems to be based on the code version that was posted in > > > >>>> February 2018, and not the latest version in OpenVZ qemu repository > > > >>>> dated October 2019: > > > >>>> > > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > > > >>>> > > > >>>> This newer version has slightly different API here and there. > > > >>>> Any particular reason for selecting that older version for porting? > > > >>>> > > > >>>> I have actually rebased this latest version on the top of the > > current > > > >>>> QEMU master, and it basically seems to work fine. > > > >>>> However, I haven't done extensive tests whether there isn't a > > memory leak > > > >>>> somewhere or so on. > > > >>>> > > > >>>> Maciej > > > > > > > > >
On 07.04.2020 20:56, Roman Kagan wrote: > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: >> Well I want it to be merged in :-) > > Hmm I'm curious why, it has little to offer over virtio. > > Anyway the series you've posted seems to be based on a fairly old > version. > > The one in openvz repo is more recent. It's still in need for > improvement, too, but should be testable at least. Isn't the one at https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus the latest one? It seems to be last changed in October 2019 - is there a later one? > Thanks, > Roman. Thanks, Maciej
On 07/04/2020, Maciej S. Szmigiero wrote: >On 07.04.2020 20:56, Roman Kagan wrote: >> On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: >>> Well I want it to be merged in :-) >> >> Hmm I'm curious why, it has little to offer over virtio. >> >> Anyway the series you've posted seems to be based on a fairly old >> version. >> >> The one in openvz repo is more recent. It's still in need for >> improvement, too, but should be testable at least. Well I have implemented the hyperv synthetic kernel debugger interface, but on Windows 10 it requires to have a working VMBus (it's not really using it, but without a function vmbus that will answer to the initiate contact then the kdnet will simply be stuck in a loop. With the synthetic kernel debugger interface you can debug older OS (Win7 up to latest Win10). The benefit is that its much faster than all other interfaces. In addition to that Michael Kelley from Microsoft has informed us that Microsoft might be dropped the synthetic kernel debugger interface sometime in the future, and it seems like the new mode is simply to use hvnet device for the communication (which is again much faster). Cheers, -- Jon. > >Isn't the one at >https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >the latest one? > >It seems to be last changed in October 2019 - is there a >later one? > >> Thanks, >> Roman. > >Thanks, >Maciej
On Tue, Apr 07, 2020 at 09:03:05PM +0200, Maciej S. Szmigiero wrote: > On 07.04.2020 20:56, Roman Kagan wrote: > > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: > >> Well I want it to be merged in :-) > > > > Hmm I'm curious why, it has little to offer over virtio. > > > > Anyway the series you've posted seems to be based on a fairly old > > version. > > > > The one in openvz repo is more recent. It's still in need for > > improvement, too, but should be testable at least. > > Isn't the one at > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > the latest one? > > It seems to be last changed in October 2019 - is there a > later one? There isn't, to the best of my knowledge. It's still sorta unfinished, though, and the demand seems to have disappeared so I couldn't find the motivation to complete it. Thanks, Roman.
On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote: > On 07/04/2020, Maciej S. Szmigiero wrote: > > On 07.04.2020 20:56, Roman Kagan wrote: > > > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: > > > > Well I want it to be merged in :-) > > > > > > Hmm I'm curious why, it has little to offer over virtio. > > > > > > Anyway the series you've posted seems to be based on a fairly old > > > version. > > > > > > The one in openvz repo is more recent. It's still in need for > > > improvement, too, but should be testable at least. > > Well I have implemented the hyperv synthetic kernel debugger interface, but > on Windows 10 it requires to have a working VMBus (it's not really using it, > but without a function vmbus that will answer to the initiate contact then > the kdnet will simply be stuck in a loop. I see, thanks, I've never heard of this before. > With the synthetic kernel debugger interface you can debug older OS (Win7 up > to latest Win10). The benefit is that its much faster than all other > interfaces. I guess you compare it to debugging via serial port. I wonder where the difference comes from? I thought the transport didn't require any significant throughput, and latency-wise the (emulated) serial port was just as good as any other. Am I missing something? Thanks, Roman. > In addition to that Michael Kelley from Microsoft has informed us that > Microsoft might be dropped the synthetic kernel debugger interface sometime > in the future, and it seems like the new mode is simply to use hvnet device > for the communication (which is again much faster). > > Cheers, > -- Jon. > > > > Isn't the one at > > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus > > the latest one? > > > > It seems to be last changed in October 2019 - is there a > > later one? > > > > > Thanks, > > > Roman. > > > > Thanks, > > Maciej
On 08.04.2020 22:26, Roman Kagan wrote: > On Tue, Apr 07, 2020 at 09:03:05PM +0200, Maciej S. Szmigiero wrote: >> On 07.04.2020 20:56, Roman Kagan wrote: >>> On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: >>>> Well I want it to be merged in :-) >>> >>> Hmm I'm curious why, it has little to offer over virtio. >>> >>> Anyway the series you've posted seems to be based on a fairly old >>> version. >>> >>> The one in openvz repo is more recent. It's still in need for >>> improvement, too, but should be testable at least. >> >> Isn't the one at >> https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >> the latest one? >> >> It seems to be last changed in October 2019 - is there a >> later one? > > There isn't, to the best of my knowledge. It's still sorta unfinished, > though, and the demand seems to have disappeared so I couldn't find the > motivation to complete it. These patches that were posted should be based on this version, that I have ported to the current QEMU master and then provided to Jon. BTW. I have written an e-mail to you about this porting work about a month ago, but it was sent your old Virtuozzo mailbox, because that's the email address that these commits had in their metadata. > Thanks, > Roman. > Thanks, Maciej
On 08/04/2020, Roman Kagan wrote: >On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote: >> On 07/04/2020, Maciej S. Szmigiero wrote: >> > On 07.04.2020 20:56, Roman Kagan wrote: >> > > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote: >> > > > Well I want it to be merged in :-) >> > > >> > > Hmm I'm curious why, it has little to offer over virtio. >> > > >> > > Anyway the series you've posted seems to be based on a fairly old >> > > version. >> > > >> > > The one in openvz repo is more recent. It's still in need for >> > > improvement, too, but should be testable at least. >> >> Well I have implemented the hyperv synthetic kernel debugger interface, but >> on Windows 10 it requires to have a working VMBus (it's not really using it, >> but without a function vmbus that will answer to the initiate contact then >> the kdnet will simply be stuck in a loop. > >I see, thanks, I've never heard of this before. > >> With the synthetic kernel debugger interface you can debug older OS (Win7 up >> to latest Win10). The benefit is that its much faster than all other >> interfaces. > >I guess you compare it to debugging via serial port. I wonder where the >difference comes from? I thought the transport didn't require any >significant throughput, and latency-wise the (emulated) serial port was >just as good as any other. Am I missing something? > >Thanks, >Roman. > Well kdcom is sending out UART through the virtual serial port, this results in very slow speeds (try it out if you get a chance), because of that most Windows kernel developers use VMWare with a combination of a tool called VirtualKD which implements it's own debug transport on the Windows part and patches the hypervisor (aka VMWare) to get the VMExits. This way it can transfer more and bigger blocks faster, to the debugger. With the synthetic debugger interface in-place (which you can use since Windows 7) all these tricks are not really required, you just need to implement it :P . Thanks, -- Jon. >> In addition to that Michael Kelley from Microsoft has informed us that >> Microsoft might be dropped the synthetic kernel debugger interface sometime >> in the future, and it seems like the new mode is simply to use hvnet device >> for the communication (which is again much faster). >> >> Cheers, >> -- Jon. >> > >> > Isn't the one at >> > https://src.openvz.org/projects/UP/repos/qemu/commits?until=refs%2Fheads%2Fvmbus >> > the latest one? >> > >> > It seems to be last changed in October 2019 - is there a >> > later one? >> > >> > > Thanks, >> > > Roman. >> > >> > Thanks, >> > Maciej
On Thu, Apr 09, 2020 at 06:35:18AM +0300, Jon Doron wrote: > On 08/04/2020, Roman Kagan wrote: > > On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote: > > > Well I have implemented the hyperv synthetic kernel debugger interface, but > > > on Windows 10 it requires to have a working VMBus (it's not really using it, > > > but without a function vmbus that will answer to the initiate contact then > > > the kdnet will simply be stuck in a loop. I tried to google for this interface but the only thing I managed to find was this https://withinrafael.com/2015/02/01/how-to-set-up-synthetic-kernel-debugging-for-hyper-v-virtual-machines/ Is this what you're trying to implement? Are there any more authoritative descriptions of the feature? The document doesn't quite explain the inner workings of the feature, but it looks like the regular network debugging interface, except that IP is forwarded by the hypervisor app, so that the debugger has to connect to the host and avoid setting up full-fledged network connectivity to the guest. That would be essentially hv-net + slirp. OTOH you say it doesn't use VMBus so I'm confused... Thanks, Roman. > > > In addition to that Michael Kelley from Microsoft has informed us that > > > Microsoft might be dropped the synthetic kernel debugger interface sometime > > > in the future, and it seems like the new mode is simply to use hvnet device > > > for the communication (which is again much faster).
On 12/05/2020, Roman Kagan wrote: >On Thu, Apr 09, 2020 at 06:35:18AM +0300, Jon Doron wrote: >> On 08/04/2020, Roman Kagan wrote: >> > On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote: >> > > Well I have implemented the hyperv synthetic kernel debugger interface, but >> > > on Windows 10 it requires to have a working VMBus (it's not really using it, >> > > but without a function vmbus that will answer to the initiate contact then >> > > the kdnet will simply be stuck in a loop. > >I tried to google for this interface but the only thing I managed to >find was this > >https://withinrafael.com/2015/02/01/how-to-set-up-synthetic-kernel-debugging-for-hyper-v-virtual-machines/ > >Is this what you're trying to implement? Are there any more >authoritative descriptions of the feature? > >The document doesn't quite explain the inner workings of the feature, >but it looks like the regular network debugging interface, except that >IP is forwarded by the hypervisor app, so that the debugger has to >connect to the host and avoid setting up full-fledged network >connectivity to the guest. That would be essentially hv-net + slirp. >OTOH you say it doesn't use VMBus so I'm confused... > >Thanks, >Roman. > >> > > In addition to that Michael Kelley from Microsoft has informed us that >> > > Microsoft might be dropped the synthetic kernel debugger interface sometime >> > > in the future, and it seems like the new mode is simply to use hvnet device >> > > for the communication (which is again much faster). Yes that's indeed the interface I have implemented this part of the patch it not full ready for commit, but I think we can keep going with the VMBUS. Based on your previous reply it sounds like there is not a real issue with the current patch of ACPI DSDT entry, right? Thanks, -- Jon.
On 12/05/2020, Jon Doron wrote: >On 12/05/2020, Roman Kagan wrote: >>On Thu, Apr 09, 2020 at 06:35:18AM +0300, Jon Doron wrote: >>>On 08/04/2020, Roman Kagan wrote: >>>> On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote: >>>> > Well I have implemented the hyperv synthetic kernel debugger interface, but >>>> > on Windows 10 it requires to have a working VMBus (it's not really using it, >>>> > but without a function vmbus that will answer to the initiate contact then >>>> > the kdnet will simply be stuck in a loop. >> >>I tried to google for this interface but the only thing I managed to >>find was this >> >>https://withinrafael.com/2015/02/01/how-to-set-up-synthetic-kernel-debugging-for-hyper-v-virtual-machines/ >> >>Is this what you're trying to implement? Are there any more >>authoritative descriptions of the feature? >> >>The document doesn't quite explain the inner workings of the feature, >>but it looks like the regular network debugging interface, except that >>IP is forwarded by the hypervisor app, so that the debugger has to >>connect to the host and avoid setting up full-fledged network >>connectivity to the guest. That would be essentially hv-net + slirp. >>OTOH you say it doesn't use VMBus so I'm confused... >> >>Thanks, >>Roman. >> >>>> > In addition to that Michael Kelley from Microsoft has informed us that >>>> > Microsoft might be dropped the synthetic kernel debugger interface sometime >>>> > in the future, and it seems like the new mode is simply to use hvnet device >>>> > for the communication (which is again much faster). > >Yes that's indeed the interface I have implemented this part of the >patch it not full ready for commit, but I think we can keep going with >the VMBUS. > >Based on your previous reply it sounds like there is not a real issue >with the current patch of ACPI DSDT entry, right? > >Thanks, >-- Jon. I suggest referring to the KVM patches I have already submitted that Paolo said will probably get in soon. https://patchwork.kernel.org/patch/11507663/
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index 2a7e55bae7..6d7fdbbe9b 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -43,6 +43,7 @@ #include "hw/acpi/tpm.h" #include "hw/acpi/vmgenid.h" #include "hw/boards.h" +#include "hw/vmbus/vmbus.h" #include "sysemu/tpm_backend.h" #include "hw/rtc/mc146818rtc_regs.h" #include "migration/vmstate.h" @@ -1270,6 +1271,43 @@ static Aml *build_com_device_aml(uint8_t uid) return dev; } +static Aml *build_vmbus_device_aml(void) +{ + Aml *dev; + Aml *method; + Aml *crs; + + dev = aml_device("VMBS"); + aml_append(dev, aml_name_decl("STA", aml_int(0xF))); + aml_append(dev, aml_name_decl("_HID", aml_string("VMBus"))); + aml_append(dev, aml_name_decl("_UID", aml_int(0x0))); + aml_append(dev, aml_name_decl("_DDN", aml_string("VMBUS"))); + + method = aml_method("_DIS", 0, AML_NOTSERIALIZED); + aml_append(method, aml_store(aml_and(aml_name("STA"), aml_int(0xD), NULL), + aml_name("STA"))); + aml_append(dev, method); + + method = aml_method("_PS0", 0, AML_NOTSERIALIZED); + aml_append(method, aml_store(aml_or(aml_name("STA"), aml_int(0xF), NULL), + aml_name("STA"))); + aml_append(dev, method); + + method = aml_method("_STA", 0, AML_NOTSERIALIZED); + aml_append(method, aml_store(aml_name("STA"), aml_local(0))); + aml_append(method, aml_return(aml_local(0))); + aml_append(dev, method); + + aml_append(dev, aml_name_decl("_PS3", aml_int(0x0))); + + crs = aml_resource_template(); + aml_append(crs, aml_irq_no_flags(7)); + aml_append(crs, aml_irq_no_flags(13)); + aml_append(dev, aml_name_decl("_CRS", crs)); + + return dev; +} + static void build_isa_devices_aml(Aml *table) { ISADevice *fdc = pc_find_fdc0(); @@ -1296,6 +1334,10 @@ static void build_isa_devices_aml(Aml *table) build_acpi_ipmi_devices(scope, BUS(obj), "\\_SB.PCI0.ISA"); } + if (vmbus_exists()) { + aml_append(scope, build_vmbus_device_aml()); + } + aml_append(table, scope); }