hw/acpi/Kconfig | 5 + hw/acpi/meson.build | 1 + hw/acpi/vmclock.c | 179 ++++++++++++++++++++++++++ hw/i386/Kconfig | 1 + hw/i386/acpi-build.c | 10 +- include/hw/acpi/vmclock.h | 34 +++++ include/standard-headers/linux/vmclock-abi.h | 182 +++++++++++++++++++++++++++ scripts/update-linux-headers.sh | 1 + 8 files changed, 412 insertions(+), 1 deletion(-) create mode 100644 hw/acpi/vmclock.c create mode 100644 include/hw/acpi/vmclock.h create mode 100644 include/standard-headers/linux/vmclock-abi.h
From: David Woodhouse <dwmw@amazon.co.uk>
The following changes since commit 6528013b5f5ba6bb3934b7f5fe57a3110680530f:
Merge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into staging (2025-01-06 09:39:02 -0500)
are available in the Git repository at:
git://git.infradead.org/users/dwmw2/qemu.git tags/pull-vmclock-20250108
for you to fetch changes up to 6502ea82b26dc28c83fbc9c766af7a408a8ca827:
hw/acpi: Add vmclock device (2025-01-07 16:22:04 +0000)
----------------------------------------------------------------
Add vmclock device
----------------------------------------------------------------
David Woodhouse (1):
hw/acpi: Add vmclock device
hw/acpi/Kconfig | 5 +
hw/acpi/meson.build | 1 +
hw/acpi/vmclock.c | 179 ++++++++++++++++++++++++++
hw/i386/Kconfig | 1 +
hw/i386/acpi-build.c | 10 +-
include/hw/acpi/vmclock.h | 34 +++++
include/standard-headers/linux/vmclock-abi.h | 182 +++++++++++++++++++++++++++
scripts/update-linux-headers.sh | 1 +
8 files changed, 412 insertions(+), 1 deletion(-)
create mode 100644 hw/acpi/vmclock.c
create mode 100644 include/hw/acpi/vmclock.h
create mode 100644 include/standard-headers/linux/vmclock-abi.h
On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org> wrote: > > From: David Woodhouse <dwmw@amazon.co.uk> > > The following changes since commit 6528013b5f5ba6bb3934b7f5fe57a3110680530f: > > Merge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into staging (2025-01-06 09:39:02 -0500) > > are available in the Git repository at: > > git://git.infradead.org/users/dwmw2/qemu.git tags/pull-vmclock-20250108 > > for you to fetch changes up to 6502ea82b26dc28c83fbc9c766af7a408a8ca827: > > hw/acpi: Add vmclock device (2025-01-07 16:22:04 +0000) > > ---------------------------------------------------------------- > Add vmclock device > > ---------------------------------------------------------------- > David Woodhouse (1): > hw/acpi: Add vmclock device > > hw/acpi/Kconfig | 5 + > hw/acpi/meson.build | 1 + > hw/acpi/vmclock.c | 179 ++++++++++++++++++++++++++ > hw/i386/Kconfig | 1 + > hw/i386/acpi-build.c | 10 +- > include/hw/acpi/vmclock.h | 34 +++++ > include/standard-headers/linux/vmclock-abi.h | 182 +++++++++++++++++++++++++++ > scripts/update-linux-headers.sh | 1 + > 8 files changed, 412 insertions(+), 1 deletion(-) > create mode 100644 hw/acpi/vmclock.c > create mode 100644 include/hw/acpi/vmclock.h > create mode 100644 include/standard-headers/linux/vmclock-abi.h On IRC you mentioned that you'd like me to pick up this pull request. If the ACPI subsystem maintainers don't want to take this through their tree then let's set up pull request handling for vmclock: 1. Add a MAINTAINERS file entry for vmclock covering the new files (e.g. hw/acpi/vmclock.c) with yourself as maintainer. 2. Send pull requests with a GPG-signed tag (git tag --sign) and ensure that the repo URL in the email is https:// (the tooling rejects unencrypted http:// and git:// repo URLs). Thank you! Stefan
On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote: > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org> > wrote: > > > > From: David Woodhouse <dwmw@amazon.co.uk> > > > > The following changes since commit > > 6528013b5f5ba6bb3934b7f5fe57a3110680530f: > > > > Merge tag 'qga-pull-2025-01-06' of > > https://github.com/kostyanf14/qemu into staging (2025-01-06 > > 09:39:02 -0500) > > > > are available in the Git repository at: > > > > git://git.infradead.org/users/dwmw2/qemu.git tags/pull-vmclock- > > 20250108 > > > > for you to fetch changes up to > > 6502ea82b26dc28c83fbc9c766af7a408a8ca827: > > > > hw/acpi: Add vmclock device (2025-01-07 16:22:04 +0000) > > > > ---------------------------------------------------------------- > > Add vmclock device > > > > ---------------------------------------------------------------- > > David Woodhouse (1): > > hw/acpi: Add vmclock device > > > > hw/acpi/Kconfig | 5 + > > hw/acpi/meson.build | 1 + > > hw/acpi/vmclock.c | 179 ++++++++++++++++++++++++++ > > hw/i386/Kconfig | 1 + > > hw/i386/acpi-build.c | 10 +- > > include/hw/acpi/vmclock.h | 34 +++++ > > include/standard-headers/linux/vmclock-abi.h | 182 +++++++++++++++++++++++++++ > > scripts/update-linux-headers.sh | 1 + > > 8 files changed, 412 insertions(+), 1 deletion(-) > > create mode 100644 hw/acpi/vmclock.c > > create mode 100644 include/hw/acpi/vmclock.h > > create mode 100644 include/standard-headers/linux/vmclock-abi.h > > On IRC you mentioned that you'd like me to pick up this pull request. > If the ACPI subsystem maintainers don't want to take this through > their tree then let's set up pull request handling for vmclock: > > 1. Add a MAINTAINERS file entry for vmclock covering the new files > (e.g. hw/acpi/vmclock.c) with yourself as maintainer. Looks like Michael has taken it now; thanks. > 2. Send pull requests with a GPG-signed tag (git tag --sign) and > ensure that the repo URL in the email is https:// (the tooling rejects > unencrypted http:// and git:// repo URLs). You mean *or* rather than *and* in that sentence, right? Because if it's GPG-signed, then I can send it to you over carrier pigeon and you can validate it; the transport is irrelevant. If you really did mean 'and'... is this a new bug in the tooling? Last time I used Peter's make-pullreq script, it worked fine¹. Obviously it doesn't matter for *this* one now Michael has picked it up, but I sent another pull request today with some Xen emulation fixes². ¹ https://lore.kernel.org/all/CAFEAcA9sjovBLdV1NsUnDGPs9hX1XYn7szbetQ-crtZ84VO4dQ@mail.gmail.com/ ² https://lore.kernel.org/qemu-devel/20250109104837.2532259-1-dwmw2@infradead.org/
On Thu, 9 Jan 2025 at 08:18, David Woodhouse <dwmw2@infradead.org> wrote: > > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote: > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org> > > wrote: > > > > > > From: David Woodhouse <dwmw@amazon.co.uk> > > > > > > The following changes since commit > > > 6528013b5f5ba6bb3934b7f5fe57a3110680530f: > > > > > > Merge tag 'qga-pull-2025-01-06' of > > > https://github.com/kostyanf14/qemu into staging (2025-01-06 > > > 09:39:02 -0500) > > > > > > are available in the Git repository at: > > > > > > git://git.infradead.org/users/dwmw2/qemu.git tags/pull-vmclock- > > > 20250108 > > > > > > for you to fetch changes up to > > > 6502ea82b26dc28c83fbc9c766af7a408a8ca827: > > > > > > hw/acpi: Add vmclock device (2025-01-07 16:22:04 +0000) > > > > > > ---------------------------------------------------------------- > > > Add vmclock device > > > > > > ---------------------------------------------------------------- > > > David Woodhouse (1): > > > hw/acpi: Add vmclock device > > > > > > hw/acpi/Kconfig | 5 + > > > hw/acpi/meson.build | 1 + > > > hw/acpi/vmclock.c | 179 ++++++++++++++++++++++++++ > > > hw/i386/Kconfig | 1 + > > > hw/i386/acpi-build.c | 10 +- > > > include/hw/acpi/vmclock.h | 34 +++++ > > > include/standard-headers/linux/vmclock-abi.h | 182 +++++++++++++++++++++++++++ > > > scripts/update-linux-headers.sh | 1 + > > > 8 files changed, 412 insertions(+), 1 deletion(-) > > > create mode 100644 hw/acpi/vmclock.c > > > create mode 100644 include/hw/acpi/vmclock.h > > > create mode 100644 include/standard-headers/linux/vmclock-abi.h > > > > On IRC you mentioned that you'd like me to pick up this pull request. > > If the ACPI subsystem maintainers don't want to take this through > > their tree then let's set up pull request handling for vmclock: > > > > 1. Add a MAINTAINERS file entry for vmclock covering the new files > > (e.g. hw/acpi/vmclock.c) with yourself as maintainer. > > Looks like Michael has taken it now; thanks. > > > 2. Send pull requests with a GPG-signed tag (git tag --sign) and > > ensure that the repo URL in the email is https:// (the tooling rejects > > unencrypted http:// and git:// repo URLs). > > You mean *or* rather than *and* in that sentence, right? Because if > it's GPG-signed, then I can send it to you over carrier pigeon and you > can validate it; the transport is irrelevant. > > If you really did mean 'and'... is this a new bug in the tooling? Last > time I used Peter's make-pullreq script, it worked fine¹. You're right, both are not required together for security. I still ask for both because we historically had some submaintainers without GPG keys and didn't want them to use unencrypted git:// or http:// URLs. It's easier if everyone does both so I don't have to check whether we've followed the right process depending on their GPG key status. I think QEMU submaintainers have now fully transitioned to GPG keys, so we could probably drop the https:// requirement. If it's not too much trouble to use https:// then that would be easiest. > > Obviously it doesn't matter for *this* one now Michael has picked it > up, but I sent another pull request today with some Xen emulation > fixes². > > ¹ https://lore.kernel.org/all/CAFEAcA9sjovBLdV1NsUnDGPs9hX1XYn7szbetQ-crtZ84VO4dQ@mail.gmail.com/ > ² https://lore.kernel.org/qemu-devel/20250109104837.2532259-1-dwmw2@infradead.org/
On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote:
> On Thu, 9 Jan 2025 at 08:18, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote:
> > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org>
> > > wrote:
> > >
> >
> > > 2. Send pull requests with a GPG-signed tag (git tag --sign) and
> > > ensure that the repo URL in the email is https:// (the tooling rejects
> > > unencrypted http:// and git:// repo URLs).
> >
> > You mean *or* rather than *and* in that sentence, right? Because if
> > it's GPG-signed, then I can send it to you over carrier pigeon and you
> > can validate it; the transport is irrelevant.
> >
> > If you really did mean 'and'... is this a new bug in the tooling? Last
> > time I used Peter's make-pullreq script, it worked fine¹.
>
> You're right, both are not required together for security. I still ask
> for both because we historically had some submaintainers without GPG
> keys and didn't want them to use unencrypted git:// or http:// URLs.
> It's easier if everyone does both so I don't have to check whether
> we've followed the right process depending on their GPG key status. I
> think QEMU submaintainers have now fully transitioned to GPG keys, so
> we could probably drop the https:// requirement.
>
> If it's not too much trouble to use https:// then that would be easiest.
I tried the 'Advanced Web Server Setup' from
https://git-scm.com/docs/gitweb :
# make the front page an internal rewrite to the gitweb script
RewriteRule ^/$ /cgi-bin/gitweb.cgi
# make access for "dumb clients" work
RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
But it seemed to break the gitweb access for URLs of the form
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
so for the *moment* I have reverted that and filed it in the 'too much
trouble' bucket. I will take another look at some point though.
On Thu, 9 Jan 2025 at 09:14, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote:
> > On Thu, 9 Jan 2025 at 08:18, David Woodhouse <dwmw2@infradead.org> wrote:
> > >
> > > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote:
> > > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org>
> > > > wrote:
> > > >
> > >
> > > > 2. Send pull requests with a GPG-signed tag (git tag --sign) and
> > > > ensure that the repo URL in the email is https:// (the tooling rejects
> > > > unencrypted http:// and git:// repo URLs).
> > >
> > > You mean *or* rather than *and* in that sentence, right? Because if
> > > it's GPG-signed, then I can send it to you over carrier pigeon and you
> > > can validate it; the transport is irrelevant.
> > >
> > > If you really did mean 'and'... is this a new bug in the tooling? Last
> > > time I used Peter's make-pullreq script, it worked fine¹.
> >
> > You're right, both are not required together for security. I still ask
> > for both because we historically had some submaintainers without GPG
> > keys and didn't want them to use unencrypted git:// or http:// URLs.
> > It's easier if everyone does both so I don't have to check whether
> > we've followed the right process depending on their GPG key status. I
> > think QEMU submaintainers have now fully transitioned to GPG keys, so
> > we could probably drop the https:// requirement.
> >
> > If it's not too much trouble to use https:// then that would be easiest.
>
> I tried the 'Advanced Web Server Setup' from
> https://git-scm.com/docs/gitweb :
>
> # make the front page an internal rewrite to the gitweb script
> RewriteRule ^/$ /cgi-bin/gitweb.cgi
>
> # make access for "dumb clients" work
> RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
> /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
>
> But it seemed to break the gitweb access for URLs of the form
> https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
> so for the *moment* I have reverted that and filed it in the 'too much
> trouble' bucket. I will take another look at some point though.
That's fine, I'll update my script to accept git://.
Thanks,
Stefan
On Thu, 2025-01-09 at 11:03 -0500, Stefan Hajnoczi wrote:
> On Thu, 9 Jan 2025 at 09:14, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote:
> > > On Thu, 9 Jan 2025 at 08:18, David Woodhouse <dwmw2@infradead.org> wrote:
> > > >
> > > > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote:
> > > > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dwmw2@infradead.org>
> > > > > wrote:
> > > > >
> > > >
> > > > > 2. Send pull requests with a GPG-signed tag (git tag --sign) and
> > > > > ensure that the repo URL in the email is https:// (the tooling rejects
> > > > > unencrypted http:// and git:// repo URLs).
> > > >
> > > > You mean *or* rather than *and* in that sentence, right? Because if
> > > > it's GPG-signed, then I can send it to you over carrier pigeon and you
> > > > can validate it; the transport is irrelevant.
> > > >
> > > > If you really did mean 'and'... is this a new bug in the tooling? Last
> > > > time I used Peter's make-pullreq script, it worked fine¹.
> > >
> > > You're right, both are not required together for security. I still ask
> > > for both because we historically had some submaintainers without GPG
> > > keys and didn't want them to use unencrypted git:// or http:// URLs.
> > > It's easier if everyone does both so I don't have to check whether
> > > we've followed the right process depending on their GPG key status. I
> > > think QEMU submaintainers have now fully transitioned to GPG keys, so
> > > we could probably drop the https:// requirement.
> > >
> > > If it's not too much trouble to use https:// then that would be easiest.
> >
> > I tried the 'Advanced Web Server Setup' from
> > https://git-scm.com/docs/gitweb :
> >
> > # make the front page an internal rewrite to the gitweb script
> > RewriteRule ^/$ /cgi-bin/gitweb.cgi
> >
> > # make access for "dumb clients" work
> > RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
> > /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
> >
> > But it seemed to break the gitweb access for URLs of the form
> > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
> > so for the *moment* I have reverted that and filed it in the 'too much
> > trouble' bucket. I will take another look at some point though.
>
> That's fine, I'll update my script to accept git://.
Thanks. I did fight it a bit longer and managed to get it to export the
repository as 'dumb' https, where it just exposes the files. Which kind
of works, but apparently not for tags. And it seems that some things
are *both* in .git/packed_refs and .git/refs/ so even pulling from some
branches gave the wrong results.
I tried to get the git-http-request thing to coexist with gitweb, but I
really have exceeded the time budget for messing with Apache now! :)
© 2016 - 2025 Red Hat, Inc.