On 13.01.2022 19:48, Andrew Cooper wrote:
> There is absolutely no need for a function pointer call here.
>
> Drop the hook, introduce a singlestep_supported boolean, and configure it in
> start_vmx() like all other optional functionality.
>
> No functional change, but rather more efficient logic
On 07.01.2022 13:55, David Vrabel wrote:
> Amazon's guest transparent live migration work needs another save
> record (for event channel upcall vectors). Reserve another HVM context
> save record ID for this.
I have to admit that I have reservations: I didn't really like seeing
the original range
On 14.01.2022 02:20, Stefano Stabellini wrote:
> On Thu, 13 Jan 2022, Jan Beulich wrote:
>> On 13.01.2022 01:58, Stefano Stabellini wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -232,7 +232,7 @@ int evtchn_allocate_port(struct domain *d,
>>> evtchn_port_t
flight 167692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167683
test-amd64-amd64-qemuu-nested-amd 20
flight 167688 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167688/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167680
test-armhf-armhf-libvirt 16 sav
On Thu, 13 Jan 2022, Juergen Gross wrote:
> > @@ -907,6 +921,20 @@ static struct notifier_block xenbus_resume_nb = {
> > .notifier_call = xenbus_resume_cb,
> > };
> > +static irqreturn_t xenbus_late_init(int irq, void *unused)
> > +{
> > + int err = 0;
> > + uint64_t v = 0;
> > +
> > +
On Thu, 13 Jan 2022, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Introduce a new "xen,enhanced" dom0less property to enable/disable PV
> > driver interfaces for dom0less guests. Currently only "enabled
On Thu, 13 Jan 2022, Jan Beulich wrote:
> On 13.01.2022 01:58, Stefano Stabellini wrote:
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -232,7 +232,7 @@ int evtchn_allocate_port(struct domain *d,
> > evtchn_port_t port)
> > return 0;
> > }
> >
> > -static
flight 167686 qemu-upstream-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167686/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 8 xen-boot fail blocked in 166943
test-amd64-amd64-qemuu
On Tue, 11 Jan 2022, Sergiy Kibrik wrote:
> Currently no IOMMU properties are exposed to dom0, thus kernel by default
> assumes no protection and enables swiotlb-xen, which leads to costly and
> unnecessary buffers bouncing.
>
> To let kernel know which device is behing IOMMU and hence needs no sw
On Thu, 13 Jan 2022, Luca Fancellu wrote:
> > On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Introduce a new "xen,enhanced" dom0less property to enable/disable PV
> > driver interfaces for dom0less guests. Currently only "enabled" and
> > "disabled"
Hi Penny,
Thanks for the update. I tested the series in a couple of different
configurations and it works great!
You can add my Tested-by to all patches
On Mon, 20 Dec 2021, Penny Zheng wrote:
> Cases where domU needs direct-map memory map:
> * IOMMU not present in the system.
> * IOMMU dis
On Mon, 20 Dec 2021, Penny Zheng wrote:
> This commit gates function make_gicv3_domU_node with CONFIG_GICV3.
>
> Signed-off-by: Penny Zheng
Acked-by: Stefano Stabellini
> ---
> v4 changes:
> - remove ASSERT_UNREACHABLE() to avoid breaking compilation on prod build with
> CONFIG_GICV3=n
> ---
On Mon, 20 Dec 2021, Penny Zheng wrote:
> Cases where domU needs direct-map memory map:
> * IOMMU not present in the system.
> * IOMMU disabled if it doesn't cover a specific device and all the guests
> are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
> a few without,
On Mon, 20 Dec 2021, Penny Zheng wrote:
> Later, we will introduce allocate_static_memory_11 for allocating static
> memory for direct-map domains, and it will share a lot common codes with
> the existing allocate_static_memory.
>
> In order not to bring a lot of duplicate codes, and also to make
flight 167684 linux-linus real [real]
flight 167691 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167684/
http://logs.test-lab.xenproject.org/osstest/logs/167691/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
flight 167683 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167683/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167677
test-amd64-amd64-qemuu-nested-amd 20
flight 167689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5302bd81d9ba0c9e7f2371a81c438ec919ec8e1e
baseline version:
ovmf 7438a85bf1388add286a8
flight 167690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167690/
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 1
There is absolutely no need for a function pointer call here.
Drop the hook, introduce a singlestep_supported boolean, and configure it in
start_vmx() like all other optional functionality.
No functional change, but rather more efficient logic.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
On 13/01/2022 17:02, Jan Beulich wrote:
> The aim being to have as few indirect calls as possible (see [1]),
> whereas during initial conversion performance was the main aspect and
> hence rarely used hooks didn't get converted. Apparently one use of
> get_interrupt_shadow() was missed at the time.
The aim being to have as few indirect calls as possible (see [1]),
whereas during initial conversion performance was the main aspect and
hence rarely used hooks didn't get converted. Apparently one use of
get_interrupt_shadow() was missed at the time.
While doing this, drop NULL checks ahead of CP
flight 167687 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167687/
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 1
These were written before Spectre/Meltdown went public, and there was large
uncertainty in how the protections would evolve. As it turns out, they're
very specific to Intel hardware, and not very suitable for AMD.
Expand and drop the macros. No change at all for VT-x.
For AMD, the only relevant
The logic was based on a mistaken understanding of how NMI blocking on vmexit
works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler path,
and the guest's value will be clobbered before it is saved.
Swi
In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will need
to be three different access methods for where the guest's value lives.
However, it would be better not to duplicate the #GP checking logic.
guest_{rd,wr}msr() are always called first in the PV and HVM MSR paths, so we
c
Andrew Cooper (3):
x86/msr: Split MSR_SPEC_CTRL handling
x86/spec-ctrl: Drop SPEC_CTRL_{ENTRY_FROM,EXIT_TO}_HVM
x86/spec-ctrl: Fix NMI race condition with VT-x MSR_SPEC_CTRL handling
xen/arch/x86/hvm/svm/entry.S | 5 ++--
xen/arch/x86/hvm/vmx/entry.S | 23 ++
On Thu, Jan 13, 2022 at 01:11:41PM +0100, Jan Beulich wrote:
> On 13.01.2022 12:22, Anthony PERARD wrote:
> > On Tue, Jan 11, 2022 at 03:16:17PM +0100, Jan Beulich wrote:
> >> Prior to 19427e439e01 ("build: generate "include/xen/compile.h" with
> >> if_changed") running "make install-xen" as root w
On Thu, Jan 13, 2022 at 11:19:46AM +, James Dingwall wrote:
> Hi,
>
> I have been trying to debug a problem where a vif with the backend in a
> driver domain is added to dom0. Intermittently the hotplug script is
> not invoked by libxl (running as xl devd) in the driver domain. By
> enabl
On 30/11/2021 18:11, Andrew Cooper wrote:
> Andrew Cooper (2):
> x86/hvm: Simplify hvm_enable_msr_interception()
> x86/hvm: Rework nested hap functions to reduce parameters
These are mechanical rather than functional changes, and the patches
have been pending for 6 weeks without objection. I'
On 13/01/2022 14:59, Jan Beulich wrote:
> On 13.01.2022 15:45, Andrew Cooper wrote:
>> On 13/01/2022 14:38, Jan Beulich wrote:
>>> On 13.01.2022 14:50, Andrew Cooper wrote:
This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
spilled to the stack is bad. Performing the
On 13.01.2022 15:45, Andrew Cooper wrote:
> On 13/01/2022 14:38, Jan Beulich wrote:
>> On 13.01.2022 14:50, Andrew Cooper wrote:
>>> This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
>>> spilled to the stack is bad. Performing the shift in a register is far more
>>> efficient
On 13/01/2022 14:38, Jan Beulich wrote:
> On 13.01.2022 14:50, Andrew Cooper wrote:
>> This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
>> spilled to the stack is bad. Performing the shift in a register is far more
>> efficient.
>>
>> Drop the (IMO useless) log message. MSR
On 13.01.2022 14:50, Andrew Cooper wrote:
> This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
> spilled to the stack is bad. Performing the shift in a register is far more
> efficient.
>
> Drop the (IMO useless) log message. MSR_PAT only gets altered on boot, and a
> bad va
This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
spilled to the stack is bad. Performing the shift in a register is far more
efficient.
Drop the (IMO useless) log message. MSR_PAT only gets altered on boot, and a
bad value will be entirely evident in the ensuing #GP backtr
Calibration logic assumes that the platform timer (HPET or ACPI PM
timer) and the TSC are read at about the same time. This assumption may
not hold when a long latency event (e.g. SMI or NMI) occurs between the
two reads. Reduce the risk of reading uncorrelated values by doing at
least four pairs o
On 13.01.2022 14:27, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 12:17:32PM +0100, Jan Beulich wrote:
>> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> For unprivileged guests vpci_{read|write} need to be re-worked
>>> to not passthrough accesses
On Thu, Nov 25, 2021 at 12:17:32PM +0100, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > For unprivileged guests vpci_{read|write} need to be re-worked
> > to not passthrough accesses to the registers not explicitly handled
> > b
On Thu, Nov 25, 2021 at 01:02:50PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> At the moment, we always allocate an extra 16 slots for IO handlers
> (see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
> MSI-X registers we need to explicitly tell t
Except in the "clocksource=tsc" case we can replace the indirect calls
involved in accessing the platform timers by direct ones, as they get
established once and never changed. To also cover the "tsc" case, invoke
what read_tsc() resolves to directly. In turn read_tsc() then becomes
unreachable and
flight 167680 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167680/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 167675
test-amd64-amd64-xl-qemuu-win7-amd6
On Wed, Jan 12, 2022 at 05:41:42PM +0100, Dario Faggioli wrote:
> If we are in libvxl_list_vcpu() and we are returning NULL, let's avoid
extra 'v' ^ here.
> touching the output parameter *nr_vcpus_out (which should contain the
> number of vcpus in the list). Ideally, the caller initialize
flight 167682 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 167685 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167685/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7438a85bf1388add286a89707079d9afca735814
baseline version:
ovmf 6062002bd5a394fef4624
On Thu, Nov 25, 2021 at 01:02:49PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> There are three originators for the PCI configuration space access:
> 1. The domain that owns physical host bridge: MMIO handlers are
> there so we can update vPCI register handlers with
On 13.01.2022 12:22, Anthony PERARD wrote:
> On Tue, Jan 11, 2022 at 03:16:17PM +0100, Jan Beulich wrote:
>> Prior to 19427e439e01 ("build: generate "include/xen/compile.h" with
>> if_changed") running "make install-xen" as root would not have printed
>> the banner under normal circumstances. Its p
On Wed, Jan 12, 2022 at 05:41:36PM +0100, Dario Faggioli wrote:
> If libxl_vcpu_list() returned NULL, we should not call
> libxl_numainfo_list_free() as:
You mean libxl_vcpuinfo_list_free() ?
> 1) it'll fail trying to (double) free() *list
This isn't really an issue. free(NULL) is legit, can be
On Wed, 2022-01-12 at 17:41 +0100, Dario Faggioli wrote:
> It is possible to encounter a segfault in libxl during concurrent
> domain
> create and destroy operations.
>
> This is because Placement of existing domains on the host's CPUs is
> examined
> when creating a new domain, but the existing l
On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> +/* Notify vPCI that device is assigned to guest. */
> +int vpci_assign_device(struct domain *d, struct pci_dev *pdev)
> +{
> +int rc;
> +
> +/
On Thu, Nov 25, 2021 at 01:02:48PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Assign SBDF to the PCI devices being passed through with bus 0.
> The resulting topology is where PCIe devices reside on the bus 0 of the
> root complex itself (embedded endpoints).
> This
On Tue, Jan 11, 2022 at 03:16:17PM +0100, Jan Beulich wrote:
> Prior to 19427e439e01 ("build: generate "include/xen/compile.h" with
> if_changed") running "make install-xen" as root would not have printed
> the banner under normal circumstances. Its printing would instead have
> indicated that some
Hi,
I have been trying to debug a problem where a vif with the backend in a
driver domain is added to dom0. Intermittently the hotplug script is
not invoked by libxl (running as xl devd) in the driver domain. By
enabling some debug for the driver domain kernel and libxl I have these
messages
On Thu, Nov 25, 2021 at 01:02:47PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Reset the command register when passing through a PCI device:
> it is possible that when passing through a PCI device its memory
> decoding bits in the command register are already set. Th
On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add basic emulation support for guests. At the moment only emulate
> PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet and left
> as TODO.
>
> Signed-off-by: Oleksandr Andrushche
On Thu, Jan 13, 2022 at 10:37:53AM +0100, Jan Beulich wrote:
> On 12.01.2022 09:55, Jan Beulich wrote:
> > @@ -504,11 +501,8 @@ static s64 __init init_pmtimer(struct pl
> >
> > count = inl(pmtmr_ioport) & mask;
> > start = rdtsc_ordered();
> > -target = count + CALIBRATE_VALUE(ACPI_
On Wed, Jan 12, 2022 at 11:01:42PM -0500, Jason Andryuk wrote:
> commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
> reflected in the config" broken PCI hotplug (xl pci-attach) for PV
> domains when it moved libxl__create_pci_backend() later in the function.
>
> This also broke
Hi Stefano,
> On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
>
> From: Luca Miccio
>
> Add an example application that can be run in dom0 to complete the
> dom0less domains initialization so that they can get access to xenstore
> and use PV drivers.
>
> Signed-off-by: Luca Miccio
> Sign
On Thu, Nov 25, 2021 at 01:02:45PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Take into account guest's BAR view and program its p2m accordingly:
> gfn is guest's view of the BAR and mfn is the physical BAR value as set
> up by the PCI bus driver in the hardware dom
Hi Stefano,
> On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
>
> From: Luca Miccio
>
> When xs_introduce_domain is called, send out a notification on the
> xenstore event channel so that any (dom0less) domain waiting for the
> xenstore interface to be ready can continue with the initializ
Hi Stefano,
+ Penny in CC for the question.
> On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
>
> From: Luca Miccio
>
> If "xen,enhanced" is enabled, then add to dom0less domains:
>
> - the hypervisor node in device tree
> - the xenstore event channel
>
> The xenstore event channel is a
On 12.01.2022 09:55, Jan Beulich wrote:
> @@ -504,11 +501,8 @@ static s64 __init init_pmtimer(struct pl
>
> count = inl(pmtmr_ioport) & mask;
> start = rdtsc_ordered();
> -target = count + CALIBRATE_VALUE(ACPI_PM_FREQUENCY);
> -if ( target < count )
> -while ( (inl(pmtmr
> On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Introduce a new "xen,enhanced" dom0less property to enable/disable PV
> driver interfaces for dom0less guests. Currently only "enabled" and
> "disabled" are supported property values (and empty). Leave the
On Wed, Jan 12, 2022 at 04:52:51PM +0100, Jan Beulich wrote:
> On 12.01.2022 16:42, Roger Pau Monné wrote:
> > On Wed, Jan 12, 2022 at 03:57:36PM +0100, Jan Beulich wrote:
> >> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> >>> @@ -379,7 +396,6 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned
On 13/01/2022 04:01, Jason Andryuk wrote:
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken PCI hotplug (xl pci-attach) for PV
domains when it moved libxl__create_pci_backend() later in the function.
This also broke HVM + stubdom PCI passthroug
Hi Stefano,
> On 13 Jan 2022, at 00:58, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Introduce a new "xen,enhanced" dom0less property to enable/disable PV
> driver interfaces for dom0less guests. Currently only "enabled" and
> "disabled" are supported property values (and empty).
On 13.01.2022 01:58, Stefano Stabellini wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -232,7 +232,7 @@ int evtchn_allocate_port(struct domain *d, evtchn_port_t
> port)
> return 0;
> }
>
> -static int get_free_port(struct domain *d)
> +int get_free_port(s
The involved asm() expands to large enough a construct that often the
compiler would decide against inlining when a containing function is
used more than once in a CU. Use the "inline" keyword when supported by
the compiler in conjunction with asm().
The INIT_SECTIONS_ONLY dependency is because in
67 matches
Mail list logo
