On Tue, 2024-09-03 at 15:56 +0200, Paolo Abeni wrote:
> I'm sorry for the late feedback.
No problem. I've addressed it all apart from the uint64_t part. I'll
concede the pre-C99 nonsense where it matches existing code, but we've
always also allowed code in the kernel to use the proper C language
t
83932 NIC to
> > fail
> > when using the normal -nic user,model=dp83932 command line.
> >
>
> Cc: qemu-sta...@nongnu.org # v9.0
> Fixes: e104edbb9d ("hw/mips/jazz: use qemu_find_nic_info()")
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhous
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 discipline that
counter against an external source of 'real' time, and
On Thu, 2024-08-22 at 12:49 +0100, Simon Horman wrote:
> Hi David,
>
> Sorry to be always the one with the nit-pick.
> Sparse complains about the line above, I believe because the
> type of st->clk->size is __le32.
>
> .../ptp_vmclock.c:562:13: warning: restricted __le32 degrades to integer
Oops
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 discipline that
counter against an external source of 'real' time, and
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On Mon, 2024-08-12 at 11:25 +0100, Peter Maydell wrote:
>
> Will this also fix
> https://gitlab.com/qemu-project/qemu/-/issues/2496 ?
Almost certainly, yes.
smime.p7s
Description: S/MIME cryptographic signature
From: David Woodhouse
Oops, don't *delete* the model option when checking for 'help'.
Fixes: 64f75f57f9d2 ("net: Reinstate '-net nic, model=help' output as
documented in man page")
Reported-by: Hans
Signed-off-by: David Woodhouse
Cc: qemu-sta...@nongnu.org
On Thu, 2024-08-01 at 05:48 -0400, Michael S. Tsirkin wrote:
> 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
On Fri, 2024-01-12 at 11:04 +, Alex Bennée wrote:
> This ensures the rootfs is never permanently changed as we don't need
> persistence between tests anyway.
>
> Message-Id: <20240103173349.398526-3-alex.ben...@linaro.org>
> Signed-off-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
>
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 that version.
> > At that point we can drop the one that's sitting alongside the
> > device itself in hw/acp
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:
>> >We don't want to manually sync headers with Linux.
>>
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
subsequently do run the script to automatically merge from Linux, before the
guest driver is merged there.
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 discipline that
counter against an external source of 'real' time, and
On Mon, 2024-07-29 at 11:33 -0400, Michael S. Tsirkin wrote:
> you said you will use __le here?
I hadn't intended to bother until we add the virtio discovery and
negotiation paths; it would basically be cosmetic for now.
Although I *will* do so with the QEMU side before posting the latest
version
On Mon, 2024-07-29 at 11:58 +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 26, 2024 at 09:44:32AM -0400, Cleber Rosa wrote:
> > Some of these tests actually require the root filesystem image,
> > obtained through Avocado's asset feature and kept in a common cache
> > location, to be writable.
Hm,
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On 28 July 2024 16:23:49 BST, "Michael S. Tsirkin" wrote:
>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&#
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 just to define a DT binding and use PRP0001 for it :)
>Long story short, QEMUVGID is indeed out of spec, but it works
>bo
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 Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
>> > &g
On 26 July 2024 15:57:34 BST, Jakub Kicinski wrote:
>On Fri, 26 Jul 2024 13:28:17 +0100 David Woodhouse wrote:
>> +` status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>
> ^ watch out for ticks!
Oops, that last minute space->tab fix after I'd already
On Fri, 2024-07-26 at 09:14 -0400, Michael S. Tsirkin wrote:
> For purposes of virtio, should we label all the fields here
> __le?
Yes. Peter and I discussed that, and it's mostly just a cosmetic change
at this point. The simple ACPI thing only exists on LE platforms for
*now* anyway.
We also had
On Fri, 2024-07-26 at 09:04 -0400, Michael S. Tsirkin wrote:
> 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:
> > >
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
> > can update. We don't need any of that complexity of gratuitously
>
On Fri, 2024-07-26 at 08:47 -0400, Michael S. Tsirkin wrote:
> 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'
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On Fri, 2024-07-26 at 02:06 -0400, Michael S. Tsirkin wrote:
> 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
On Fri, 2024-07-26 at 01:55 -0400, Michael S. Tsirkin wrote:
> 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 inte
On Thu, 2024-07-25 at 17:47 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > Those people included me. I wanted to interrupt all the vCPUs, even the
> > ones which were in userspace at the moment of migration, and have the
>
On Thu, 2024-07-25 at 17:04 -0400, Michael S. Tsirkin wrote:
> 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 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 04:18:43PM +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
> > course; this is for those applications which *need* precision time.
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
> > able to expose it via PCI, I probably wouldn't do it that way. There&#x
On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> 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: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 10:56:05AM +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 than
> > > trying to keep two specs in sync.
> >
> > The ACPI
On Thu, 2024-07-25 at 12:31 +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Hi Michael, thanks for the review!
> >
> > On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> > > Do you want to just
On Thu, 2024-07-25 at 13:20 +0200, Paolo Abeni wrote:
>
>
> Just a bunch of 'nits below
Thank you. Fixed in
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
I'll post a new version once I've finished resolving mst's and any
other feedback.
smime.p7s
Description: S/
On Thu, 2024-07-25 at 01:54 -0400, Michael S. Tsirkin wrote:
> one other thing worth mentioning is that this design can't work
> with confidential computing setups. By comparison, mapping e.g. a
> range in a PCI BAR would work for these setups.
Why so? This is just like mapping a PCI BAR, isn't it
Hi Michael, thanks for the review!
On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> 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 prec
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 cloning of virtual machines, but
it explicitly *doesn't* change on live migration.
smime.p7s
Description: S/M
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 discipline that
counter against an external source of 'real' time, and
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On Tue, 2024-07-23 at 16:15 +0200, Paolo Bonzini wrote:
> On Tue, Jun 25, 2024 at 2:03 PM TaiseiIto wrote:
> > Before this commit, interruptions from i8254 which should be sent to IRQ0
> > were sent to IRQ2. After this commit, these are correctly sent to IRQ0. When
> > I had an HPET timer generate
On Tue, 2024-07-09 at 15:46 +0300, Michael Tokarev wrote:
> 09.07.2024 15:34, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > While refactoring the NIC initialization code, I broke '-net nic,model=help'
> > which no longer outputs a list of
On Tue, 2024-07-16 at 05:13 +, Sandesh Patel wrote:
>
>
> > On 11 Jul 2024, at 5:22 PM, Sandesh Patel wrote:
> >
> > Thanks David for all the analysis.
> > >
> > > Looking at the Linux guest support, it seems to look just at the HyperV
> > > CPUID leaves 0x4081 and 0x4082. QEMU kno
On Tue, 2024-07-16 at 15:20 +0200, Peter Hilber wrote:
> On 16.07.24 14:32, David Woodhouse wrote:
> > On 16 July 2024 12:54:52 BST, Peter Hilber
> > wrote:
> > > On 11.07.24 09:50, David Woodhouse wrote:
> > > > On Thu, 2024-07-11 at 09:25 +0200, Peter Hil
On Tue, 2024-07-16 at 13:54 +0200, Peter Hilber wrote:
> On 08.07.24 11:27, David Woodhouse wrote:
> > +
> > + /*
> > + * Time according to time_type field above.
> > + */
> > + uint64_t time_sec; /* Seconds since time_t
On 16 July 2024 12:54:52 BST, Peter Hilber wrote:
>On 11.07.24 09:50, David Woodhouse wrote:
>> On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
>>>
>>> IMHO this phrasing is better, since it directly refers to the state of the
>>> structure.
>>
&
On Thu, 2024-07-11 at 08:26 +0100, David Woodhouse wrote:
>
> I used identical command lines on both, and on each host I got the same
> result with all of '-cpu host', '-cpu EPYC' and -cpu Skylake-Server'.
> It's the *host* that makes the differen
On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
>
> IMHO this phrasing is better, since it directly refers to the state of the
> structure.
Thanks. I'll update it.
> AFAIU if there would be abnormal delays in store buffers, causing some
> driver to still see the old clock for some time, t
On Mon, 2024-07-08 at 10:13 +0100, David Woodhouse wrote:
> On Wed, 2024-07-03 at 16:01 +, Sandesh Patel wrote:
> > >
> > > Interesting. What exactly has Windows *done* in those MSI entries?
> > > That might give a clue about how to support it.
I repeated my
On Wed, 2024-07-10 at 15:07 +0200, Peter Hilber wrote:
> On 08.07.24 11:27, 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
From: David Woodhouse
While refactoring the NIC initialization code, I broke '-net nic,model=help'
which no longer outputs a list of available NIC models.
Fixes: 2cdeca04adab ("net: report list of available models according to
platform")
Signed-off-by: David Woodhouse
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On Mon, 2024-07-08 at 10:17 +0100, Simon Horman wrote:
> Hi David,
>
> As per my comment on v2, although it is harmless in this case,
> it would be nicer to use strscpy() here and avoid fortification
> warnings.
>
Oh, pants! I have fixed that; must have sent the wrong version.
V4 coming up short
On Wed, 2024-07-03 at 16:01 +, Sandesh Patel wrote:
> >
> > Interesting. What exactly has Windows *done* in those MSI entries?
> > That
> > might give a clue about how to support it.
>
> The KVM_SET_GSI_ROUTING ioctl calls kvm_set_routing_entry function in
> kvm.
>
> int kvm_set_routing_entr
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 cross timestamps into
KVM clock values. Unlike the KVM PTP clock,
On Wed, 2024-07-03 at 18:48 -0400, Michael S. Tsirkin wrote:
> From: David Woodhouse
Oops, that was supposed to be
From: David Woodhouse
Not the end of the world if it's too late to change it.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2024-07-02 at 05:17 +, Sandesh Patel wrote:
> Hi All,
> Is it possible to setup a large Windows VM (say 512 vcpus) without
> adding viommu (EIM=on, IR=on)?
> When I try to power such VM, the qemu process crashes with error-
> ```
> qemu-kvm: ../accel/kvm/kvm-all.c:1837: kvm_irqchip_comm
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. We use NTP/PTP/PPS to discipline that counter against an
external source of 'real' time, and track t
x27;t check for error
anyway.
Signed-off-by: David Woodhouse
---
v2: Make the table static and introduce e820_get_table(), use assert()
hw/i386/e820_memory_layout.c | 16 +++-
hw/i386/e820_memory_layout.h | 8 ++--
hw/i386/fw_cfg.c | 18 +-
hw/i386/fw_
On Mon, 2024-06-17 at 15:15 +0100, Peter Maydell wrote:
> On Mon, 17 Jun 2024 at 14:46, David Woodhouse wrote:
> >
> > From: David Woodhouse
> >
> > In e820_add_entry() the e820_table is reallocated with g_renew() to make
> > space for a new entry. However, f
From: David Woodhouse
In e820_add_entry() the e820_table is reallocated with g_renew() to make
space for a new entry. However, fw_cfg_arch_create() just uses the existing
e820_table pointer.
This leads to a use-after-free if anything adds a new entry after fw_cfg
is set up. Shift the addition
On 27 March 2024 13:31:52 GMT, Anthony PERARD wrote:
>On Tue, Nov 14, 2023 at 03:38:05PM +0100, Philippe Mathieu-Daudé wrote:
>> Except imported source files, QEMU code base uses
>> the QEMU_ALIGNED() macro to align its structures.
>
>This patch only convert the alignment, but discard pack. We nee
On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> I think what James is looking for (and what we are also interested
> in), is _eliminating_ the ability to access guest memory from the
> direct map entirely. And in general, eliminate the ability to access
> guest memory in as many ways as p
nings by manually connecting every NIC
> on the board to some backend.
>
> Signed-off-by: Peter Maydell
Reviewed-by: David Woodhouse
... although do we want to expand this test to cover the GMACs?
smime.p7s
Description: S/MIME cryptographic signature
unity to use the -nic commandline
> option to create a network backend and connect it to the GMACs.
>
> Add the missing call.
>
> Fixes: 21e5326a7c ("hw/arm: Add GMAC devices to NPCM7XX SoC")
> Signed-off-by: Peter Maydell
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2024-02-02 at 16:15 +, Peter Maydell wrote:
> On Fri, 2 Feb 2024 at 16:01, David Woodhouse wrote:
> >
> > What is the next step? Post the full series as a v5, or perhaps just
> > the single fixed patch which is now at
> > https://git.infradead.org/?p=users/
From: David Woodhouse
Create the device only if there is a corresponding NIC config for it.
Remove the explicit check on nd_table[0].used from hw/hppa/machine.c
which (since commit d8a3220005d7) tries to do the same thing.
The lasi_82596 support has been disabled since it was first introduced
From: David Woodhouse
The following changes since commit c3709fde5955d13f6d4f86ab46ef3cc2288ca65e:
Merge tag 'pull-aspeed-20240201' of https://github.com/legoater/qemu into
staging (2024-02-01 14:42:11 +)
are available in the Git repository at:
git://git.infradead.org/u
From: David Woodhouse
Create the device only if there is a corresponding NIC config for it.
Remove the explicit check on nd_table[0].used from hw/hppa/machine.c
which (since commit d8a3220005d7) tries to do the same thing.
The lasi_82596 support has been disabled since it was first introduced
On Fri, 2024-02-02 at 15:32 +, Peter Maydell wrote:
>
> $ ./build/all/qemu-system-hppa -M C3700
> Segmentation fault (core dumped)
Ah, got it. Some HPPA machine types don't have a lasi_dev.
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -362,9 +362,11 @@ static void machine_HP_common_in
On Fri, 2024-02-02 at 15:32 +, Peter Maydell wrote:
>
> This fails "make check' because some of the qom-test and
> test-hmp checks fail when the QEMU binary segfaults.
>
> https://gitlab.com/qemu-project/qemu/-/jobs/6084552256
> https://gitlab.com/qemu-project/qemu/-/jobs/6084044180
Thanks.
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/alpha/dp264.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 03495e1e60..52a1fa310b 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
From: David Woodhouse
Previously, the first PCI NIC would be placed in PCI slot 3 and the rest
would be dynamically assigned. Even if the user overrode the default NIC
type and made it something other than PCNet.
Now, the first PCNet NIC (that is, anything not explicitly specified
to be
From: David Woodhouse
Most code which directly accesses nd_table[] and nb_nics uses them for
one of two things. Either "I have created a NIC device and I'd like a
configuration for it", or "I will create a NIC device *if* there is a
configuration for it". With some var
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
Xen and ISA NICs first and then calling pci_init_nic_devices() for the
rest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/pc.c| 31
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/m68k/mcf5208.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index d22d8536db..0cfb806c20 100644
--- a/hw/m68k/mcf5208.c
+++ b
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Leif Lindholm
---
hw/arm/sbsa-ref.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 85cb68d546..f2adf30337 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa
From: David Woodhouse
When converting to the shiny build-system-du-jour, a typo prevented the
last_i82596 driver from being built. Correct the config option name to
re-enable the build. And include "sysemu/sysemu.h" so it actually builds.
Fixes: b1419fa66558 ("meson: convert hw
ic options
--------
David Woodhouse (47):
net: add qemu_{configure,create}_nic_device(), qemu_find_nic_info()
net: report list of available models according to platform
net: add qemu_create_nic_bus_devices()
h
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/ppc/e500.c | 4 +---
hw/ppc/mac_newworld.c | 4 +---
hw/ppc/mac_oldworld.c | 4 +---
hw/ppc/ppc440_bamboo.c | 14 +-
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/arm/fsl-imx25.c | 2 +-
hw/arm/fsl-imx6.c | 2 +-
hw/arm/fsl-imx6ul.c | 2 +-
hw/arm/fsl-imx7.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/arm/fsl-imx25.c b/hw/arm/fsl
From: David Woodhouse
Signed-off-by: David Woodhouse
Acked-by: Thomas Huth
---
hw/s390x/s390-virtio-ccw.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c99682b07d..62804cc228 100644
--- a/hw/s390x
From: David Woodhouse
If a corresponding NIC configuration was found, it will have a MAC address
already assigned, so use that. Else, generate and assign a default one.
Using qemu_find_nic_info() is simpler than the alternative of using
qemu_configure_nic_device() and then having to fetch the
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/xtensa/xtfpga.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c
index fbad1c83a3..f49e6591dc 100644
--- a/hw/xtensa/xtfpga.c
+++ b/hw
From: David Woodhouse
Some callers instantiate the device unconditionally, others will do so only
if there is a NICInfo to go with it. This appears to be fairly random, but
preserve the existing behaviour of each caller for now.
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw
From: David Woodhouse
Create the device only if there is a corresponding NIC config for it.
Remove the explicit check on nd_table[0].used from hw/hppa/machine.c
which (since commit d8a3220005d7) tries to do the same thing.
The lasi_82596 support has been disabled since it was first introduced
From: David Woodhouse
The loop over nd_table[] to add PCI NICs is repeated in quite a few
places. Add a helper function to do it.
Some platforms also try to instantiate a specific model in a specific
slot, to match the real hardware. Add pci_init_nic_in_slot() for that
purpose.
Signed-off-by
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/microblaze/petalogix_ml605_mmu.c | 3 +--
hw/microblaze/petalogix_s3adsp1800_mmu.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/microblaze/petalogix_ml605_mmu.c
b/hw
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/mips/jazz.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index 0d2348aa5a..5bf3e328db 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
From: David Woodhouse
By noting the models for which a configuration was requested, we can give
the user an accurate list of which NIC models were actually available on
the platform/configuration that was otherwise chosen.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
net
From: David Woodhouse
Obtain the MAC address from the NIC configuration if there is one, or
generate one explicitly so that it can be placed in the PROM.
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/sparc/sun4m.c | 20 ++--
1 file changed, 14 insertions
From: David Woodhouse
These old functions can be removed now too. Let net_param_nic() print
the full set of network devices directly, and also make it note that a
list more specific to this platform/config will be available by using
'-nic model=help' instead.
Signed-off-by: David
From: David Woodhouse
Signed-off-by: David Woodhouse
Acked-by: Cédric Le Goater
Reviewed-by: Cédric Le Goater
---
hw/arm/aspeed.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index cc59176563..bed5e4f40b 100644
--- a/hw/arm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/xtensa/virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index a6cf646e99..5310a88861 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
From: David Woodhouse
Also update the test to specify which device to attach the test socket
to, and remove the comment lamenting the fact that we can't do so.
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/arm/npcm7xx.c | 16 +---
tests/
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/cris/axis_dev88.c | 9 -
hw/net/etraxfs_eth.c | 5 ++---
include/hw/cris/etraxfs.h | 2 +-
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/hw/cris/axis_dev88.c b/hw/cris
From: David Woodhouse
Avoid directly referencing nd_table[] by first instantiating any
spapr-vlan devices using a qemu_get_nic_info() loop, then calling
pci_init_nic_devices() to do the rest.
No functional change intended.
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/ppc
1 - 100 of 1130 matches
Mail list logo
