On Mon, Aug 05, 2024 at 11:27:27PM +0800, luzhixing12345 wrote:
> Signed-off-by: luzhixing12345
>
> >On Sun, Aug 04, 2024 at 10:23:53PM GMT, luzhixing12345 wrote:
> >>rewrite with if-else instead of goto
> >
> >Why?
> >
> >IMHO was better before this patch with a single error path.
>
> I think t
On Mon, Aug 05, 2024 at 06:37:58PM +0900, Akihiko Odaki wrote:
> If cross-migrate=off, QEMU can still migrate on the same host (checkpoint
> and restart). QEMU can also migrate across hosts if the user ensures they
> are on the same platform.
What is so special about checkpoint/restart? I guess we
On Mon, Aug 05, 2024 at 04:10:02PM +0900, Akihiko Odaki wrote:
> On 2024/08/05 15:39, Michael S. Tsirkin wrote:
> > On Sun, Aug 04, 2024 at 06:01:36PM +0900, Akihiko Odaki wrote:
> > > Supersedes: <20240714-rombar-v2-0-af1504ef5...@daynix.com>
> > > ("[PATC
On Mon, Aug 05, 2024 at 04:53:52PM +0900, Akihiko Odaki wrote:
> On 2024/08/05 16:30, Michael S. Tsirkin wrote:
> > On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> > > I suggest disabling all offload features of virtio-net with 9.2.
> >
> > Yea ...
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> I suggest disabling all offload features of virtio-net with 9.2.
Yea ... no.
> I want to keep things consistent so I want to disable all at once. This
> change will be very uncomfortable for us, who are implementing offload
> featur
h "hw/qdev: Remove opts member".
> - Link to v9:
> https://lore.kernel.org/r/20240315-reuse-v9-0-67aa69af4...@daynix.com
>
> Changes in v9:
> - Rebased.
> - Restored '#include "qapi/error.h"' (Michael S. Tsirkin)
> - Added patch "pcie_sriov: E
On Sun, Aug 04, 2024 at 09:08:05AM -0400, Peter Xu wrote:
> On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> > On 2024/08/03 1:26, Peter Xu wrote:
> > > On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki wrote:
> > > > > > > I'm not sure if I read it right. Perhaps you meant s
On Fri, Aug 02, 2024 at 02:17:56PM +0900, Akihiko Odaki wrote:
> Disable SR-IOV VF devices by reusing code to power down PCI devices
> instead of removing them when the guest requests to disable VFs. This
> allows to realize devices and report VF realization errors at PF
> realization time.
What k
On Sat, Aug 03, 2024 at 12:38:10AM +0900, Akihiko Odaki wrote:
> On 2024/08/02 21:58, Michael S. Tsirkin wrote:
> > On Fri, Aug 02, 2024 at 02:17:58PM +0900, Akihiko Odaki wrote:
> > > num_vfs is not migrated so use PCI_SRIOV_CTRL_VFE and PCI_SRIOV_NUM_VF
> > > instead.
On Fri, Aug 02, 2024 at 12:26:22PM -0400, Peter Xu wrote:
> And that's why I was thinking (where I totally agree with you on this) that
> whether we should settle a short term plan first to be on the safe side
> that we start with migration always being compatible, then we figure the
> other approa
On Fri, Aug 02, 2024 at 01:30:51PM +0900, Akihiko Odaki wrote:
> 4) is the second easiest to implement, but the design of 4) will depend on
> whether we will satisfy 2) or 3). In the email I cited earlier, I suggested
> an option -use-platform to specify the expectation on the platform. If it is
>
On Fri, Aug 02, 2024 at 10:34:37AM +0300, Yuri Benditovich wrote:
> At the moment kernel (vhost) and vhost user backends do not support
> this feature (and IMO they do not need to)
> In order to support it they need to implement a) coalescing of
> segmented TCP packets and b) population of respecti
On Fri, Aug 02, 2024 at 02:17:58PM +0900, Akihiko Odaki wrote:
> num_vfs is not migrated so use PCI_SRIOV_CTRL_VFE and PCI_SRIOV_NUM_VF
> instead.
>
> Signed-off-by: Akihiko Odaki
> ---
> include/hw/pci/pcie_sriov.h | 1 -
> hw/pci/pcie_sriov.c | 28
> hw/pc
On Thu, Aug 01, 2024 at 04:45:17PM +0100, Daniel P. Berrangé wrote:
> So to ensure a QEMU is started with migration compatible features
> will still require teaching libvirt about every single feature
> that has a host kernel dependancy, so libvirt (or the app using
> libvirt) knows to turn this of
On Thu, Aug 01, 2024 at 11:36:19AM -0400, Peter Xu wrote:
> On Thu, Aug 01, 2024 at 01:51:00AM -0400, Michael S. Tsirkin wrote:
> > So I suggest a single command that dumps some description of host
> > features, to be passed to qemu on destination. qemu then fails to
> > st
set.
> >
> > Mention the datasheet referenced. Remove the "Malta assumptions
> > ahead" comment since the reset values from the datasheet are used.
> >
> > Reported-by: Michael S. Tsirkin
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> &
On Thu, Aug 01, 2024 at 11:13:37AM -0400, Peter Xu wrote:
> Do we really concern about users not enabling features that much? I
> thought users always can manually change the XML and add whatever they
> need, and device properties do not like too special here to me. I mean, we
> have bunch of "fe
On Thu, Aug 01, 2024 at 04:56:30PM +0200, Philippe Mathieu-Daudé wrote:
> When booting Linux we see:
>
> PCI host bridge to bus :00
> pci_bus :00: root bus resource [mem 0x1000-0x17ff]
> pci_bus :00: root bus resource [io 0x1000-0x1f]
> pci_bus :00: No busn res
On Thu, Aug 01, 2024 at 04:56:30PM +0200, Philippe Mathieu-Daudé wrote:
> When booting Linux we see:
>
> PCI host bridge to bus :00
> pci_bus :00: root bus resource [mem 0x1000-0x17ff]
> pci_bus :00: root bus resource [io 0x1000-0x1f]
> pci_bus :00: No busn res
On Thu, Aug 01, 2024 at 08:45:40PM +0800, BillXiang wrote:
> From: BillXiang
>
> Currently, we have added VHOST_USER_SET_LOG_BASE to
> vhost_user_per_device_request in commit 7c211eb078c4
> ("vhost-user: Skip unnecessary duplicated VHOST_USER_SET_LOG_BASE requests"),
> as a result, VHOST_USER_
On Thu, Aug 01, 2024 at 02:36:11PM +0200, Philippe Mathieu-Daudé wrote:
> On 1/8/24 12:27, Michael S. Tsirkin wrote:
> > On Thu, Aug 01, 2024 at 12:07:42PM +0200, Philippe Mathieu-Daudé wrote:
> > > When BAR aren't configured, we get:
> > >
> > >(qem
On Thu, Aug 01, 2024 at 08:20:35PM +0800, BillXiang wrote:
>
> > From: "Michael S. Tsirkin"
> > Date: Thu, Aug 1, 2024, 18:26
> > Subject: Re: [PATCH v2] vhsot-user: Do not wait for replay for not sent
> > VHOST_USER_SET_LOG_BASE
> > To: "BillX
On Thu, Aug 01, 2024 at 12:59:57PM +0200, Markus Armbruster wrote:
> Akihiko Odaki writes:
>
> > On 2024/07/31 17:32, Markus Armbruster wrote:
> >> Akihiko Odaki writes:
> >>
> >>> rom_bar is tristate but was defined as uint32_t so convert it into
> >>> OnOffAuto to clarify that. For compatibil
This reverts commit 107a64b9a360cf5ca046852bc03334f7a9f22aef.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/pcie_sriov.h | 2 --
hw/pci/pci.c| 7 ---
hw/pci/pcie_sriov.c | 7 ---
3 files changed, 16 deletions(-)
diff --git a/include/hw/pci/pcie_sriov.h b
This reverts commit cbd9e5120bac3e292eee77b7a2e3692f235a1a26.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/pcie_sriov.h | 1 +
hw/pci/pcie_sriov.c | 28
hw/pci/trace-events | 2 +-
3 files changed, 10 insertions(+), 21 deletions(-)
diff
This reverts commit 723c5b4628d047e43825a046c6ee517b82b88117.
Signed-off-by: Michael S. Tsirkin
---
hw/ppc/spapr_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index f63182a03c..7cf9904c35 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc
naro.org>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/amd_iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 6d4fde72f9..87643d2891 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/
This reverts commit 47cc753e50076c25334091783738be9f716253b1.
Signed-off-by: Michael S. Tsirkin
---
hw/pci/pcie_sriov.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 15a4aac1f4..6c79658b4c 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci
This reverts commit 77718701157f6ca77ea7a57b536fa0a22f676082.
Signed-off-by: Michael S. Tsirkin
---
docs/pcie_sriov.txt | 8 +++-
include/hw/pci/pcie_sriov.h | 5 ++---
hw/net/igb.c| 13 +++--
hw/nvme/ctrl.c | 24
hw
This reverts commit 26f86093ec989cb73ad03e8a234f5dc321e1e267.
Signed-off-by: Michael S. Tsirkin
---
hw/ppc/spapr_pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index ed4454bbf7..f63182a03c 100644
--- a/hw/ppc/spapr_pci.c
ED90090 (0x7fc95281c090): 0x1DA801
Check DW field(bit11) is 1.
Signed-off-by: yeeli
Message-Id: <20240725031858.1529902-1-seven.yi@gmail.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/intel_iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
This reverts commit 3f868ffb0bae0c4feafabe34a371cded57fe3806.
Signed-off-by: Michael S. Tsirkin
---
include/hw/virtio/virtio-pci.h | 1 -
hw/virtio/virtio-pci.c | 20 +---
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/include/hw/virtio/virtio-pci.h b
This reverts commit 6a31b219a5338564f3978251c79f96f689e037da.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/pci.h| 7 +--
include/hw/pci/pci_device.h | 2 +-
hw/pci/pci.c| 14 +++---
hw/pci/pci_host.c | 4 ++--
4 files changed, 11
This reverts commit 1a9bf009012e590cb166a4a9bae4bc18fb084d76.
Signed-off-by: Michael S. Tsirkin
---
hw/pci/pcie_sriov.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 9bd7f8acc3..faadb0d2ea 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci
This reverts commit c613ad25125bf3016aa8f81ce170f5ac91d2379f.
Signed-off-by: Michael S. Tsirkin
---
hw/pci/pcie_sriov.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 499becd527..e9b23221d7 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci
This reverts commit 139610ae67f6ecf92127bb7bf53ac6265b459ec8.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/pci.h| 5 ++
include/hw/pci/pci_device.h | 15 --
include/hw/pci/pcie_sriov.h | 1 +
hw/pci/pci.c| 2 +-
hw/pci/pcie_sriov.c | 95
This reverts commit ca6dd3aef8a103138c99788bcba8195d4905ddc5.
Signed-off-by: Michael S. Tsirkin
---
hw/pci/pci.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index cf2794879d..4c7be52951 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
This reverts commit c2d6db6a1f39780b24538440091893f9fbe060a7.
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio-net-pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/virtio/virtio-net-pci.c b/hw/virtio/virtio-net-pci.c
index dba4987d6e..e03543a70a 100644
--- a/hw/virtio/virtio
This reverts commit d6f40c95b35bd380340b698e4306704fe22a5d68.
Signed-off-by: Michael S. Tsirkin
---
MAINTAINERS | 1 -
docs/system/index.rst | 1 -
docs/system/sriov.rst | 36
3 files changed, 38 deletions(-)
delete mode 100644 docs/system
with max-bytes set to 0, quota is 0 and so device does not work.
block this to avoid user confusion
Message-Id:
<73a89a42d82ec8b47358f25119b87063e4a6ea57.1721818306.git@redhat.com>
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
---
hw/virtio/virtio-rng
This reverts commit 122173a5830f7757f8a94a3b1559582f312e140b.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/pci_device.h | 6 +-
include/hw/pci/pcie_sriov.h | 18 ---
hw/pci/pci.c| 62 +++-
hw/pci/pcie_sriov.c | 290
4
This reverts commit 78f9d7fd1989311040beff54979bcb2a1ba0aff2.
Signed-off-by: Michael S. Tsirkin
---
hw/pci/pcie_sriov.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 6c79658b4c..56523ab4e8 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci
x27;s request
a couple of fixes in virtio,vtd
Signed-off-by: Michael S. Tsirkin
------------
Michael S. Tsirkin (17):
virtio-rng: block max-bytes=0
Revert "docs: Document composable SR-IOV device"
Revert "v
On Thu, Aug 01, 2024 at 12:07:42PM +0200, Philippe Mathieu-Daudé wrote:
> When BAR aren't configured, we get:
>
> (qemu) info pci
> Bus 0, device 0, function 0:
> Host bridge: PCI device dead:beef
> ...
> BAR4: 32 bit memory at 0x [0x0ffe].
>
On Thu, Aug 01, 2024 at 05:48:36PM +0800, BillXiang wrote:
>
> > From: "Michael S. Tsirkin"
> > Date: Thu, Aug 1, 2024, 16:26
> > Subject: Re: [PATCH v2] vhsot-user: Do not wait for replay for not sent
> > VHOST_USER_SET_LOG_BASE
> > To: "BillX
On Thu, Aug 01, 2024 at 11:13:32AM +0200, Philippe Mathieu-Daudé wrote:
> When booting Linux we see:
>
> PCI host bridge to bus :00
> pci_bus :00: root bus resource [mem 0x1000-0x17ff]
> pci_bus :00: root bus resource [io 0x1000-0x1f]
> pci_bus :00: No busn res
On Thu, Aug 01, 2024 at 09:49:06AM +0100, David Woodhouse wrote:
> On Wed, 2024-07-31 at 17:19 -0400, Michael S. Tsirkin wrote:
> >
> > > Perfect. So as and when the header is in its final form in Linux,
> > > it can be part of the automated import and we'll use t
On Thu, Aug 01, 2024 at 11:35:19AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 01.07.24 23:55, Michael S. Tsirkin wrote:
> > On Mon, Jul 01, 2024 at 08:42:39AM -0400, Raphael Norwitz wrote:
> > > I have no issues with these APIs, but I'm not a QMP expert so others
&g
On Sun, Jul 21, 2024 at 11:20:56AM +0800, BillXiang wrote:
>
> > From: "Michael S. Tsirkin"
> > Date: Sun, Jul 21, 2024, 03:01
> > Subject: Re: [PATCH v2] vhsot-user: Do not wait for replay for not sent
> > VHOST_USER_SET_LOG_BASE
> > To: "
g the not reached assertions later
> > when converting to internal QEMU values.
> >
> > Reported-by: Zheyu Ma
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2416
> > Signed-off-by: Manos Pitsidianakis
> > Message-Id:
> > Reviewed-by: Philipp
On Thu, Aug 01, 2024 at 04:01:44PM +0900, Akihiko Odaki wrote:
> rom_bar_set() and and underlying visit_type_str_preserving() are ugly, but
> we can remove them once the deprecation period ends. On the other hand, if
> we don't make this change, dev->opts will keep floating around, and we will
> ev
On Thu, Aug 01, 2024 at 04:13:14PM +0900, Akihiko Odaki wrote:
> I think it is a good idea to revert these patches for now
OK I reverted the 2 patchsets. there were some bugfixes there
but I had to revert them too due to the dependency.
If appropriate, feel free to resubmit just the fixes.
--
MS
On Thu, Aug 01, 2024 at 02:37:55PM +0900, Akihiko Odaki wrote:
> I don't know much about vDPA-capable device, but as a reference, igb only
> has 8 VFs.
modern vdpa capable devices have much more than 8 VFs, 8 is a very low
number.
--
MST
On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote:
> Could you elaborate why it would fail if with what I proposed?
First I think I was wrong I misunderstood what you said.
To summarise, you said:
- any new feature depending on another package is off by default
- starting qemu on destinati
On Fri, Jul 26, 2024 at 07:39:46PM +0200, Thomas Huth wrote:
> Anyway, while we're discussing solutions: We are in softfreeze already.
> Should we disable the UFO bits in the new 9.1 machine type for the time
> being to avoid that more people are running into this problem?
At the moment I'm lookin
On Tue, Jul 30, 2024 at 02:02:27AM +0900, Akihiko Odaki wrote:
> I think it is simpler to analyze the platform dependency and dump it for the
> management layer. For example, libvirt can request QEMU to analyze the
> platform dependency when it creates a new domain. QEMU will then figure out
> that
On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote:
> >
> > The right solution is to have a tool that can query
> > backends, and that given the results from all of the cluster,
> > generate a set of parameters that will ensure migration works.
> > Kind of like qemu-img, but for migration.
>
On Wed, Jul 31, 2024 at 01:23:49AM +0100, David Woodhouse wrote:
> On 30 July 2024 21:45:53 BST, "Michael S. Tsirkin" wrote:
> >On Tue, Jul 30, 2024 at 08:04:17PM +0100, David Woodhouse wrote:
> >> On 30 July 2024 18:53:18 BST, "Michael S. Tsirkin" wrote
On Wed, Jul 31, 2024 at 10:32:19AM +0200, Markus Armbruster wrote:
> Whether it would be worth your trouble and mine just to clean up
> "rombar" seems highly dubious, though.
Exactly.
--
MST
On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> > > On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote:
> &
On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote:
> > This is not what we did historically. Why should we start now?
>
> It's a matter of whether we still want migration to randomly fail, like
&g
On Tue, Jul 30, 2024 at 08:04:17PM +0100, David Woodhouse wrote:
> On 30 July 2024 18:53:18 BST, "Michael S. Tsirkin" wrote:
> >We don't want to manually sync headers with Linux.
>
> Indeed. I was briefly tempted to fake it, but figured it might get lost if we
&g
On Tue, Jul 30, 2024 at 03:11:03PM -0400, Peter Xu wrote:
> On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote:
> > > On Mon, Jul 29, 2024 at 06:26:41PM +0100, Daniel P. Berrangé wrote:
> > > > On Mon, Jul 29, 2024 at 01:
On Fri, Jul 19, 2024 at 12:20:53PM +0200, Dominic Prinz wrote:
> This patch implements the periodic and the swsmi ICH9 chipset timer. They are
> especially useful when prototyping UEFI firmware (e.g. with EDK2's OVMF)
> with QEMU.
>
> This includes that writes to the SMI_STS register are enabled f
On Tue, Jul 30, 2024 at 09:26:20PM +0900, Akihiko Odaki wrote:
> On 2024/07/30 20:37, Michael S. Tsirkin wrote:
> > On Mon, Jul 15, 2024 at 02:19:06PM +0900, Akihiko Odaki wrote:
> > > Based-on: <20240714-rombar-v2-0-af1504ef5...@daynix.com>
> > > ("[PATC
> diff --git a/hw/acpi/vmclock-abi.h b/hw/acpi/vmclock-abi.h
> new file mode 100644
> index 00..19cbf85efd
> --- /dev/null
> +++ b/hw/acpi/vmclock-abi.h
> @@ -0,0 +1,186 @@
> +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
> BSD-2-Clause) */
> +
> +/*
> + * This structur
On Mon, Jul 15, 2024 at 02:19:06PM +0900, Akihiko Odaki wrote:
> Based-on: <20240714-rombar-v2-0-af1504ef5...@daynix.com>
> ("[PATCH v2 0/4] hw/pci: Convert rom_bar into OnOffAuto")
OK I will revert this for now. We'll try again after the release,
there will be time to address s390.
On Tue, Jul 30, 2024 at 01:24:30PM +0200, Igor Mammedov wrote:
> On Mon, 22 Jul 2024 08:45:58 +0200
> Mauro Carvalho Chehab wrote:
>
> > There is one reference to ACPI 4.0 and several references
> > to ACPI 6.x versions.
> >
> > Update them to point to ACPI 6.5 whenever possible.
>
> when it co
On Tue, Jul 30, 2024 at 11:07:11AM +0200, Laurent Vivier wrote:
> On 24/07/2024 12:51, Michael S. Tsirkin wrote:
> > with max-bytes set to 0, quota is 0 and so device does not work.
> > block this to avoid user confusion
> >
> > Signed-off-by: Michael S. Tsirkin
>
On Mon, Jul 29, 2024 at 11:42:22AM +0100, David Woodhouse wrote:
> +struct vmclock_abi {
> + /* CONSTANT FIELDS */
> + uint32_t magic;
> +#define VMCLOCK_MAGIC0x4b4c4356 /* "VCLK" */
> + uint32_t size; /* Size of region containing this structure */
> + uint16_t vers
On Mon, Jul 29, 2024 at 03:39:03PM +0800, Yi Liu wrote:
> On 2024/7/18 16:16, Zhenzhong Duan wrote:
> > From: Yu Zhang
> >
> > Spec revision 3.0 or above defines more detailed fault reasons for
> > scalable mode. So introduce them into emulation code, see spec
> > section 7.1.2 for details.
> >
On Sun, Jul 28, 2024 at 02:07:01PM +0100, David Woodhouse wrote:
> On 28 July 2024 11:37:04 BST, "Michael S. Tsirkin" wrote:
> >Glad you asked :)
>
> Heh, I'm not sure I'm so glad. Did I mention I hate ACPI? Perhaps it's still
> not too late for me
On Fri, Jul 26, 2024 at 07:28:28PM +0100, David Woodhouse wrote:
> On 26 July 2024 17:49:58 BST, Jonathan Cameron
> wrote:
> >On Thu, 25 Jul 2024 14:50:50 +0100
> >David Woodhouse wrote:
> >
> >> On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
>
On Fri, Jul 26, 2024 at 01:28:17PM +0100, David Woodhouse wrote:
> diff --git a/include/uapi/linux/vmclock-abi.h
> b/include/uapi/linux/vmclock-abi.h
> new file mode 100644
> index ..7b1b4759363c
> --- /dev/null
> +++ b/include/uapi/linux/vmclock-abi.h
> @@ -0,0 +1,187 @@
> +/* SPDX-Li
On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:
> On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > > But for this use case, we only need a memory region that the hypervisor
&g
On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> But for this use case, we only need a memory region that the hypervisor
> can update. We don't need any of that complexity of gratuitously
> interrupting all the vCPUs just to ensure that none of them can be
> running userspace whil
On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> That's great. You don't even need it to be per-vCPU if you let the
> hypervisor write directly to the single physical location that's mapped
> to userspace. It can do that before it even starts *running* the vCPUs
> after migration.
On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
> On 26/07/2024 08.08, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote:
> > > On Tue, Aug 01, 2023 at 01:31:48AM +0300, Yuri Benditovich wrote:
> > > > USO features
On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote:
> On Tue, Aug 01, 2023 at 01:31:48AM +0300, Yuri Benditovich wrote:
> > USO features of virtio-net device depend on kernel ability
> > to support them, for backward compatibility by default the
> > features are disabled on 8.0 and earlier.
>
On Thu, Jul 25, 2024 at 11:20:56PM +0100, David Woodhouse wrote:
> We're rolling out the AMZNVCLK device for internal use cases, and plan
> to add it in public instances some time later.
Let's be real. If amazon does something in its own hypervisor, and the
only way to use that is to expose the in
On Fri, Jul 26, 2024 at 01:09:24AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > > >
> > > > > To me that see
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > > devic
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > > devic
On Thu, Jul 25, 2024 at 10:00:24PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > > &
On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > > The use case isn't necessarily for all users of gettimeofday(), of
&g
On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 10:11 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> > > Even if the virtio-rtc specification were official today, and I was
> >
On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> Even if the virtio-rtc specification were official today, and I was
> able to expose it via PCI, I probably wouldn't do it that way. There's
> just far more in virtio-rtc than we need; the simple shared memory
> region is perfectly
On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > &
On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > Do you want to just help complete virtio-rtc then? Would be easier t
On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Do you want to just help complete virtio-rtc then? Would be easier than
> > trying to keep two specs in sync.
>
> The ACPI version is much more lightweight and doesn't take up a
> valuable PCI slot#. (I know, you can do virtio wi
On Thu, Jul 25, 2024 at 10:22:15AM +0200, Igor Mammedov wrote:
> On Thu, 13 Jun 2024 18:30:15 +0100
> Jiaxun Yang wrote:
>
> > Implement S3 and S4 sleep with ACPI_GED_REG_SLEEP_CTL.SLP_TYP
> > writes.
> >
> > Implement wakeup callback and WAK_STS register to inform guest
> > about current states
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based c
On Wed, Jul 24, 2024 at 07:45:31PM +0100, David Woodhouse wrote:
> On Wed, 2024-07-24 at 13:29 -0400, Michael S. Tsirkin wrote:
> >
> > Isn't the existing vmgenid sufficient for this disruption marker
> > and if not, why?
>
> No, VMGENID handles snapshotting and
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based c
On Wed, Jul 24, 2024 at 06:22:42PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock device addresses the problem of live migration with
> precision clocks. The tolerances of a hardware counter (e.g. TSC) are
> typically around ±50PPM. A guest will use NTP/PTP/PPS to disciplin
with max-bytes set to 0, quota is 0 and so device does not work.
block this to avoid user confusion
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio-rng.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c
index
On Tue, Jul 23, 2024 at 10:44:36AM +1000, Richard Henderson wrote:
> On 7/23/24 10:20, Michael S. Tsirkin wrote:
> > > Fails ubsan testing:
> > >
> > > https://gitlab.com/qemu-project/qemu/-/jobs/7397450714
> > >
> > > ../publish/hw/net/vi
Li
Tested-by: Miguel Luis
Reviewed-by: Shaoqin Huang
Tested-by: Zhao Liu
Acked-by: Igor Mammedov
Message-Id: <20240716111502.202344-7-salil.me...@huawei.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/exec/cpu-common.h | 8
include/hw/core
-by: Sunil V L
Acked-by: Alistair Francis
Reviewed-by: Igor Mammedov
Message-Id: <20240716144306.2432257-3-suni...@ventanamicro.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/riscv/virt-acpi-build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Goater
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/vfio/common.c | 3 ++-
hw/vfio/trace-events | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 6d15b36e0b..cfc44a4569 100644
--- a/hw/vfio/common.c
++
101 - 200 of 13126 matches
Mail list logo
