Signed-off-by: Jun Nie
---
xen/arch/arm/Kconfig.debug | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 842d768280..fefe8ac4df 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -158,6 +158,9 @@ choice
On Wed, Oct 25, 2023 at 06:32:26PM -0700, Stefano Stabellini wrote:
> On Wed, 25 Oct 2023, Vikram Garhwal wrote:
> > From: Juergen Gross
> >
> > Add the callbacks for mapping/unmapping guest memory via grants to the
> > special grant memory region.
> >
> > Signed-off-by: Juergen Gross
> >
flight 183532 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183532/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9bb5ef1287c6765c477fb2cb3107339f700ab419
baseline version:
ovmf
flight 183529 xen-unstable real [real]
flight 183533 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183529/
http://logs.test-lab.xenproject.org/osstest/logs/183533/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, 25 Oct 2023, Vikram Garhwal wrote:
> From: Juergen Gross
>
> Add the callbacks for mapping/unmapping guest memory via grants to the
> special grant memory region.
>
> Signed-off-by: Juergen Gross
> Signed-off-by: Vikram Garhwal
> ---
> hw/xen/xen-mapcache.c | 175
On Wed, 25 Oct 2023, Vikram Garhwal wrote:
> From: Juergen Gross
>
> Add a memory region which can be used to automatically map granted
> memory. It is starting at 0x8000ULL in order to be able to
> distinguish it from normal RAM.
>
> For this reason the xen.ram memory region is
On Thu, 26 Oct 2023, David Woodhouse wrote:
> On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> > From: Juergen Gross
> >
> > Virtio devices should never be unplugged at boot time, as they are
> > similar to pci passthrough devices.
> >
> > Signed-off-by: Juergen Gross
> >
On Wed, 25 Oct 2023, Jan Beulich wrote:
> On 25.10.2023 03:15, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Jan Beulich wrote:
> >> On 24.10.2023 01:31, Stefano Stabellini wrote:> --- a/docs/misra/rules.rst
> >>> +++ b/docs/misra/rules.rst
> >>> @@ -422,6 +422,13 @@ maintainers if you want
On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> From: Juergen Gross
>
> Virtio devices should never be unplugged at boot time, as they are
> similar to pci passthrough devices.
>
> Signed-off-by: Juergen Gross
> Signed-off-by: Vikram Garhwal
Hm, do your virtio NICs still actually
Implement a basic exception handler that dumps the CPU state to the
console, as well as the code required to set the correct exception
vector table's base address in setup.c.
Signed-off-by: Shawn Anastasio
---
v3:
- Add comment to explain %r1 clobber
- Add comment about ISR declaration order
Hello all,
This series implements a basic exception handler and the required
support infrastructure on Power. Currently the handler just dumps all
registers to the serial console and nothing else, but even this is
useful for debugging during early bring-up.
Thanks,
Shawn Anastasio (2):
On Power, the exception vectors must lie at a fixed address, depending
on the state of the Alternate Interrupt Location (AIL) field of the
Logical Partition Control Register (LPCR). Create a .text.exceptions
section in the linker script at an address suitable for AIL=3 plus an
accompanying
On Wed, 25 Oct 2023, Jan Beulich wrote:
> On 25.10.2023 16:50, Nicola Vetrini wrote:
> > Ok, I'll send a revised version using MASK_LOWEST_BIT, taking into
> > account also the
> > other comments about the explanation on the macro definition
> > (which some IDEs even show when hovering on its
On Wed, 25 Oct 2023, Nicola Vetrini wrote:
> On 24/10/2023 21:50, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> > > On 24/10/2023 10:14, Jan Beulich wrote:
> > > > On 24.10.2023 10:01, Nicola Vetrini wrote:
> > > > > On 24/10/2023 09:50, Jan Beulich wrote:
> > > > > >
On Wed, 2023-10-25 at 17:10 +0100, David Woodhouse wrote:
> On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> > On 24.10.23 15:45, David Woodhouse wrote:
> > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > > >
> > > > > I can probably change xen_send_IPI_one() to not need
>
On Wed, 25 Oct 2023, Jan Beulich wrote:
> On 24.10.2023 22:30, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> >> As specified in rules.rst, these constants can be used
> >> in the code.
> >>
> >> Signed-off-by: Nicola Vetrini
> >> ---
> >> Changes in v2:
> >> - replace
On 10/20/23 1:22 AM, Jan Beulich wrote:
> On 19.10.2023 22:02, Shawn Anastasio wrote:
>> On 10/18/23 10:43 AM, Jan Beulich wrote:
>>> On 13.10.2023 20:13, Shawn Anastasio wrote:
--- a/xen/arch/ppc/setup.c
+++ b/xen/arch/ppc/setup.c
@@ -11,6 +11,15 @@
/* Xen stack for bringing
flight 183523 linux-5.4 real [real]
flight 183531 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183523/
http://logs.test-lab.xenproject.org/osstest/logs/183531/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
From: Juergen Gross
Add the callbacks for mapping/unmapping guest memory via grants to the
special grant memory region.
Signed-off-by: Juergen Gross
Signed-off-by: Vikram Garhwal
---
hw/xen/xen-mapcache.c | 175 +-
system/physmem.c | 11 ++-
2
From: Juergen Gross
Virtio devices should never be unplugged at boot time, as they are
similar to pci passthrough devices.
Signed-off-by: Juergen Gross
Signed-off-by: Vikram Garhwal
---
docs/system/i386/xen.rst | 3 ---
hw/i386/xen/xen_platform.c | 10 --
2 files changed, 8
From: Juergen Gross
Add a memory region which can be used to automatically map granted
memory. It is starting at 0x8000ULL in order to be able to
distinguish it from normal RAM.
For this reason the xen.ram memory region is expanded, which has no
further impact as it is used just as
From: Juergen Gross
Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
case it can't find a matching entry for a pointer value. Both cases
are bad, so change that to return an invalid address instead.
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
On Wed, 25 Oct 2023, Julien Grall wrote:
> On 25/10/2023 17:01, Jan Beulich wrote:
> > On 25.10.2023 17:58, Julien Grall wrote:
> > > On 25/10/2023 09:18, Jan Beulich wrote:
> > > > On 24.10.2023 21:59, Stefano Stabellini wrote:
> > > > > If I understood correctly I am fine with that. To make sure
On Wed, 25 Oct 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 24/10/2023 20:52, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Bertrand Marquis wrote:
> > > Hi Julien,
> > >
> > > > On 24 Oct 2023, at 12:28, Julien Grall wrote:
> > > >
> > > > From: Julien Grall
> > > >
> > > > In commit
On 25/10/2023 8:29 pm, Edwin Török wrote:
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 483b5e4f70..b3cd851d9d 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -584,6 +584,13 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t
> val)
> }
>
On Wed, 25 Oct 2023, Jan Beulich wrote:
> On 25.10.2023 10:35, Luca Fancellu wrote:
> > I’m sending this mail looking for feedbacks about generalising the
> > exclude-list.json, as suggested (IIRC) by Jan
> > this list can be used by multiple users and not only for MISRA, by adding a
> > field
On Wed, 25 Oct 2023, Jan Beulich wrote:
> On 25.10.2023 11:35, Michal Orzel wrote:
> >
> >
> > On 25/10/2023 11:26, Jan Beulich wrote:
> >>
> >>
> >> On 25.10.2023 11:21, Michal Orzel wrote:
> >>> On 25/10/2023 11:10, Jan Beulich wrote:
> On 25.10.2023 10:28, Michal Orzel wrote:
> > At
On Wed, 25 Oct 2023, Andrew Cooper wrote:
> I know it was me who dropped microcode_init_{intel,amd}() in c/s
> dd5f07997f29 ("x86/ucode: Rationalise startup and family/model checks"), but
> times have moved on. We've gained new conditional support, and a wish to
> compile-time specialise Xen to
On 25/10/2023 8:29 pm, Edwin Török wrote:
> From: Edwin Török
>
> Xen forbids writes to the various turbo control MSRs, however
> MSR_PLATFORM_INFO claims that these MSRs are writable.
> Override MSR_PLATFORM_INFO bits to indicate lack of support.
>
> See Intel SDM Volume 4, 2.17.6 "MSRs
From: Edwin Török
AnyThread deprecation means a bit in 0xa edx, which we pass through.
(we could also avoid doing the anythread masking, but we need that
for version <= 4 support).
Fixed Counter enumeration means we need to limit fixed counters if we
hide any.
Domain separation needs no
From: Edwin Török
Instruction retired perf counter, enabled by writing to a bit in HWCR.
Signed-off-by: Edwin Török
---
xen/arch/x86/include/asm/msr-index.h| 1 +
xen/arch/x86/msr.c | 7 +++
xen/include/public/arch-x86/cpufeatureset.h | 2 +-
3 files
From: Edwin Török
Now that we have a way to set PERF_GLOBAL_STATUS by writing to
PERF_GLOBAL_STATUS_RESET (== PERF_GLOBAL_OVF_CTRL) and
PERF_GLOBAL_STATUS_SET we do not need to intercept this MSR anymore.
We can save/restore its state when saving/loading vPMU state, and
otherwise let the guest
On 10/20/23 13:33, Julien Grall wrote:
> Hi Stewart,
>
> On 09/10/2023 20:57, Stewart Hildebrand wrote:
>> Set the pci flags in xen_arch_domainconfig to enable vPCI for dom0.
>>
>> Signed-off-by: Stewart Hildebrand
>> ---
>> Julien had a suggestion to make this conditional on
From: Edwin Török
These are available, but were hidden by CPUID previously.
There are IR (all guests), NB and L2I (dom0 only) performance counters too
that need to be implemented, add placeholder entries for them.
Signed-off-by: Edwin Török
---
xen/arch/x86/cpu-policy.c |
From: Edwin Török
The behaviour is changed from Legacy to Streamlined for the LBR and
PERFMON freeze bits.
See "17.4.7 Freezing LBR and Performance Counters on PMI".
Instead of clearing the freeze bits through DEBUGCTL they are now
cleared through MSR 0x390 like everything else.
Signed-off-by:
From: Edwin Török
Expose MSR_TURBO_RATIO_LIMIT{,1,2} and MSR_TEMPERATURE_TARGET to guest as RO.
Although these are not architectural MSRs they are in the same place
currently on all supported CPUs.
They also have the same meaning, except for 06_55H and 06_5C where
they have a different meaning
From: Edwin Török
This ensures consistency between the 2 pieces of code that check for
VPMU version.
No functional change.
Signed-off-by: Edwin Török
---
xen/arch/x86/cpu/vpmu_intel.c | 20 ++--
xen/arch/x86/include/asm/vpmu.h | 1 +
2 files changed, 7 insertions(+), 14
From: Edwin Török
This is not yet exposed by HVM policies, but PMU version 2 requires that
if PDCM is supported in CPUID then these 2 bits would work.
Signed-off-by: Edwin Török
---
xen/arch/x86/hvm/vmx/vmx.c | 4
xen/arch/x86/include/asm/msr-index.h | 4 +++-
2 files changed,
From: Edwin Török
Dom0 should always be able to read this MSR: it is useful when
investigating performance issues in production.
Although the count is Thread scoped, in practice all cores were observed
to return the same count (perhaps due to implementation details of SMM),
so do not require the
From: Edwin Török
Depends on the other x86/PMUv4 patches:
"x86/PMUv4: disable intercept for PERF_GLOBAL_STATUS"
"x86/PMUv4: IA32_PERF_GLOBAL_{STATUS_SET, INUSE} support"
"x86/PMUv4: support LBR_Frz and CTR_Frz"
Signed-off-by: Edwin Török
---
xen/arch/x86/include/asm/vpmu.h | 2 +-
1 file
From: Edwin Török
Add most architectural MSRs, except those behind CPUID features that are
not yet implemented, such as TME, SGX.
Based on "2.1 Architectural MSRs" of Intel SDM volume 4
Signed-off-by: Edwin Török
---
xen/arch/x86/include/asm/msr-index.h | 54 +---
1
From: Edwin Török
The 0xa CPUID leaf has to report supported number of:
- fixed performance counters
- general purpose performance counters
- architectural predefined events
And the PMU version (which was already limited to 3).
Type punning is used, which should be safe due to
From: Edwin Török
Xen forbids writes to the various turbo control MSRs, however MSR_PLATFORM_INFO
claims that these MSRs are writable.
Override MSR_PLATFORM_INFO bits to indicate lack of support.
See Intel SDM Volume 4, 2.17.6 "MSRs Introduced in the Intel Xeon Scaslable
Processor Family",
From: Edwin Török
This is part of 'Architectural Performance Monitoring Version 1'
and implemented on Icelake.
Backport: 4.13+
Signed-off-by: Edwin Török
---
xen/arch/x86/cpu/vpmu_intel.c | 1 +
xen/arch/x86/cpuid.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Edwin Török
The code is currently inconsistent: supports 4 on read and 8 on write.
Sandy Bridge+ supports 8 of these, and the MSR range is architecturally
reserved, so always support 8.
Make it a macro to ensure we use the same value everywhere.
Although DomUs are now restricted to only
From: Edwin Török
Marked as exposed by default, but then hidden if vpmu is not available.
TODO: the interaction between vpmu and policy might need some changes.
Only expose LBR and the full-width MSR capabilities, and not PEBS.
Backport: 4.15+
Signed-off-by: Edwin Török
---
From: Edwin Török
Expose thse MSRs to the guest when PMU version is >= 4.
Signed-off-by: Edwin Török
---
xen/arch/x86/cpu/vpmu_intel.c | 20 +++-
xen/arch/x86/hvm/vmx/vmx.c | 5 +
xen/arch/x86/pv/emul-priv-op.c | 5 +
3 files changed, 29 insertions(+), 1
From: Edwin Török
There are only 3 architectural fixed function counters defined,
however Icelake introduces a 4th.
So we'll need to report the number of fixed counter implemented in CPUID
correctly for Icelake, define a macro to ensure we are consistent about
which counter is last.
Note:
From: Edwin Török
Only PERFEVTSEL{0-3} are architectural MSRs and Thread scoped.
PERFEVTSEL{4-7} are Core scoped, and we cannot allow using them if more
than 1 guest can attempt to modify them: if they program them with
different events (quite likely when multiplexing) then one of the VMs
would
From: Edwin Török
This is needed so we can expose the maximum supported in CPUID,
without cpuid.c and vpmu_intel.c going out of sync.
The macros defined here take a parameter that controls how the enum
values are used: either to generate case statements or to count how many
elements we have.
From: Edwin Török
To more easily lookup the semantics of these MSRs add references to
vendor manuals.
Signed-off-by: Edwin Török
---
xen/arch/x86/include/asm/msr-index.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/x86/include/asm/msr-index.h
These are a set of patches to improve performance monitoring in Xen.
It starts by fixing MSR_PLATFORM_INFO and making MSR_SMI_COUNT available.
Also allows a pinned Dom0 to read any MSR, there is no reason why this
shouldn't be allowed, and it prevents having to recompile Xen in order to
From: Edwin Török
This can be useful if you realize you have to inspect the value of an
MSR in production, without having to change into a new Xen first that
handles the MSR.
E.g. SMI count didn't use to be explicitly allowed in the past
(it now is, see a previous commit), but there could be
On 10/20/23 13:29, Julien Grall wrote:
> Hi,
>
> On 09/10/2023 20:57, Stewart Hildebrand wrote:
>> From: Oleksandr Andrushchenko
>>
>> VPCI is disabled on ARM. Make it depend on d->arch.has_vpci to enable the PCI
>> passthrough support on ARM.
>>
>> While here, remove the comment on the
On 10/20/23 13:25, Julien Grall wrote:
> On 09/10/2023 20:57, Stewart Hildebrand wrote:
>> Add a flag to struct xen_arch_domainconfig to allow specifying at domain
>> creation time whether the domain uses vPCI.
>>
>> Add a corresponding flag to struct arch_domain to indicate vPCI and set it
>>
On Wed, 2023-10-25 at 19:56 +0100, Andrew Cooper wrote:
> On 25/10/2023 7:26 pm, David Woodhouse wrote:
>
> > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> >
> > > On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> >
> > >
> > > > +
> > > > +Booting Xen PV guests
>
On 25/10/2023 7:26 pm, David Woodhouse wrote:
> On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
>> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
>>> +
>>> +Booting Xen PV guests
>>> +-
>>> +
>>> +Booting PV guest kernels is possible by using the Xen PV
On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Add notes about console and network support, and how to launch PV guests.
> > Clean up the disk configuration examples now that that's
On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Add notes about console and network support, and how to launch PV guests.
> Clean up the disk configuration examples now that that's simpler, and
> remove the comment about IDE unplug on q35/AHCI now
We eventually want to be able to build a stripped down Xen for a single
platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
available to randconfig), and adjust the microcode logic.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
I know it was me who dropped microcode_init_{intel,amd}() in c/s
dd5f07997f29 ("x86/ucode: Rationalise startup and family/model checks"), but
times have moved on. We've gained new conditional support, and a wish to
compile-time specialise Xen to single platform.
(Re)introduce
A fix to the recent Ucode changes which I ultimately didn't insist on owing to
the Xen 4.18 timeline, and enough of the start on the CPU Kconfig to allow
randconfig to check the boundary.
There are many more ucode fixes to come...
Andrew Cooper (2):
x86/ucode: Move vendor specifics back out of
Hi Ayan,
On 25/10/2023 19:03, Ayan Kumar Halder wrote:
> Before the MMU is turned on, the address returned for any symbol will always
> be
> physical address. Thus, one can use adr_l instead of load_paddr.
>
> create_table_entry() now takes an extra argument to denote if it is called
> after
>
flight 183526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183526/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 884ef984541c3e346d39e423fea53cf25066ff5a
baseline version:
ovmf
Before the MMU is turned on, the address returned for any symbol will always be
physical address. Thus, one can use adr_l instead of load_paddr.
create_table_entry() now takes an extra argument to denote if it is called after
the mmu is turned on or not. If it is called with mmu on, then it uses
On 25/10/2023 17:01, Jan Beulich wrote:
On 25.10.2023 17:58, Julien Grall wrote:
On 25/10/2023 09:18, Jan Beulich wrote:
On 24.10.2023 21:59, Stefano Stabellini wrote:
If I understood correctly I am fine with that. To make sure we are all
on the same page, can you provide a couple of
flight 183522 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183522/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail pass in 183519
test-armhf-armhf-libvirt-qcow2
On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> On 24.10.23 15:45, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > >
> > > > I can probably change xen_send_IPI_one() to not need
> > > > irq_get_chip_data().
> > >
> > > David, could you test the
On 25.10.2023 17:58, Julien Grall wrote:
> On 25/10/2023 09:18, Jan Beulich wrote:
>> On 24.10.2023 21:59, Stefano Stabellini wrote:
>>> If I understood correctly I am fine with that. To make sure we are all
>>> on the same page, can you provide a couple of samples?
>>
>> Taking the earlier
Hi,
On 25/10/2023 09:18, Jan Beulich wrote:
On 24.10.2023 21:59, Stefano Stabellini wrote:
If I understood correctly I am fine with that. To make sure we are all
on the same page, can you provide a couple of samples?
Taking the earlier example, instead of DRIVERS_PASSTHROUGH_VTD_DMAR_H it
On Wed, 2023-10-25 at 12:42 -0300, Daniel Henrique Barboza wrote:
>
> I believe you forgot to remove the 'nd' variable. Building with this patch
> (applying
> patches 1 to 4 first) fails with:
>
>
> ../hw/riscv/microchip_pfsoc.c: In function ‘microchip_pfsoc_soc_realize’:
>
On 10/22/23 12:51, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/riscv/microchip_pfsoc.c | 13 ++---
hw/riscv/sifive_u.c| 7 +--
2 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/hw/riscv/microchip_pfsoc.c
flight 183525 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183525/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 25.10.2023 16:50, Nicola Vetrini wrote:
> Ok, I'll send a revised version using MASK_LOWEST_BIT, taking into
> account also the
> other comments about the explanation on the macro definition
> (which some IDEs even show when hovering on its usage, which could
> partially address
> the latter
From: David Woodhouse
A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do this after
From: David Woodhouse
When fire_watch_cb() found the response buffer empty, it would call
deliver_watch() to generate the XS_WATCH_EVENT message in the response
buffer and send an event channel notification to the guest… without
actually *copying* the response buffer into the ring. So there was
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git
From: David Woodhouse
There's no need to force the user to assign a vdev. We can automatically
assign one, starting at xvda and searching until we find the first disk
name that's unused.
This means we can now allow '-drive if=xen,file=xxx' to work without an
explicit separate -driver argument,
From: David Woodhouse
This will instantiate any NICs which live on a given bus type. Each bus
is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for
Xen it's xen → xen-net-device; no point in overengineering it unless we
actually want more).
Signed-off-by: David Woodhouse
---
From: David Woodhouse
When instantiating XenBus itself, for each NIC which is configured with
either the model unspecified, or set to to "xen" or "xen-net-device",
create a corresponding xen-net-device for it.
Now we can launch emulated Xen guests with '-nic user', and this fixes
the setup for
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
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code
From: David Woodhouse
This allows us to use Xen PV networking with emulated Xen guests, and to
add them on the command line or hotplug.
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
hw/net/xen_nic.c | 484
From: David Woodhouse
Upstream Xen now ignores this flag¹, since the only guest kernel ever to
use it was buggy.
¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 20
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 variants on the theme around
From: David Woodhouse
In net_cleanup() we only need to delete the netdevs, as those may have
state which outlives Qemu when it exits, and thus may actually need to
be cleaned up on exit.
The nics, on the other hand, are owned by the device which created them.
Most devices don't bother to clean
From: David Woodhouse
This allows (non-primary) console devices to be created on the command
line and hotplugged.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 532 +++-
From: David Woodhouse
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need
From: David Woodhouse
The per-vCPU upcall vector support had three problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT when
the guest tried to set it up. Secondly it was using the wrong ioctl() to
pass the vector to the kernel and thus the *kernel* would
From: David Woodhouse
When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful
also to unplug the peer of the *Xen* PV NIC.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
From: David Woodhouse
The refcounts actually correspond to 'active_ref' structures stored in a
GHashTable per "user" on the backend side (mostly, per XenDevice).
If we zero map_track[] on reset, then when the backend drivers get torn
down and release their mapping we hit the
From: David Woodhouse
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature,
which will come in a subsequent commit.
Signed-off-by: David Woodhouse
Acked-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/arch-arm.h | 37
From: David Woodhouse
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 11
Round up a handful of outstanding fixes, add console support and fix up
per-vCPU upcall vector support (which was previously untested), and that
allows us to boot PV guests using the Xen "PV shim".
Having fixed up the per-vCPU upcall vector support, pull in slightly
newer Xen headers just for
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
---
net/net.c | 94
From: David Woodhouse
This confuses lscpu into thinking it's running in PVH mode.
Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version")
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 1 -
1 file changed, 1 deletion(-)
diff --git
From: David Woodhouse
Even on x86_64 the default protocol is the x86-32 one if the guest doesn't
specifically ask for x86-64.
Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and
disconnect functions...")
Signed-off-by: David Woodhouse
---
hw/block/xen-block.c | 6 +-
From: David Woodhouse
To support Xen guests using the Q35 chipset, the unplug protocol needs
to also remove AHCI disks.
Make pci_xen_ide_unplug() more generic, iterating over the children
of the PCI device and destroying the "ide-hd" devices. That works the
same for both AHCI and IDE, as does
From: David Woodhouse
The primary console is special because the toolstack maps a page into
the guest for its ring, and also allocates the guest-side event channel.
The guest's grant table is even primed to export that page using a known
grant ref#. Add support for all that in emulated mode, so
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
ISA NICs first and then calling pci_init_nic_devices() for the test.
It's important to do this *before* the subsequent patch which registers
the Xen PV network devices, because the code being remove
1 - 100 of 161 matches
Mail list logo
