Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 08/02/18 06:37, Alexey G wrote: > On Wed, 7 Feb 2018 13:01:08 + > Igor Druzhinin <igor.druzhi...@citrix.com> wrote: >> So far the issue confirmed: >> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >> that it was tested on), Intel S2600XX,

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 06/02/18 16:23, Jan Beulich wrote: On 06.02.18 at 17:14, wrote: >> On 06/02/18 16:07, Jan Beulich wrote: >> On 05.02.18 at 22:18, wrote: --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -34,7 +34,8 @@

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 06/02/18 16:23, Jan Beulich wrote: On 06.02.18 at 17:14, wrote: >> On 06/02/18 16:07, Jan Beulich wrote: >> On 05.02.18 at 22:18, wrote: --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -34,7 +34,8 @@

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 06/02/18 17:08, Alexey G wrote: > On Tue, 6 Feb 2018 14:21:12 + > Andrew Cooper wrote: > >> On 06/02/18 03:10, Alexey G wrote: >>> I/O port 61h normally is not emulated by SMI legacy kbd handling code >>> in BIOS, only ports like 60h, 64h, etc. >>> Contrary to

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 06/02/18 16:07, Jan Beulich wrote: On 05.02.18 at 22:18, wrote: >> --- a/xen/arch/x86/nmi.c >> +++ b/xen/arch/x86/nmi.c >> @@ -34,7 +34,8 @@ >> #include >> >> unsigned int nmi_watchdog = NMI_NONE; >> -static unsigned int nmi_hz = HZ; >> +/* initial watchdog

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 06/02/18 16:23, Jan Beulich wrote: On 06.02.18 at 17:14, wrote: >> On 06/02/18 16:07, Jan Beulich wrote: >> On 05.02.18 at 22:18, wrote: --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -34,7 +34,8 @@

[Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

conditions. As the result, the system is constantly moving between NMI and SMI handler and not making any progress. Just lower the initial frequency for now as we lower it later even more anyway. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- xen/arch/x86/nmi.c | 3 ++-

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 13:08, Jan Beulich wrote: On 07.02.18 at 14:01, wrote: >> So far the issue confirmed: >> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >> that it was tested on), Intel S2600XX, etc. >> >> Also see: >>

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 09:13, Jan Beulich wrote: On 06.02.18 at 22:51, wrote: >> The problem with a quirk/commandline parameter is that the issue is >> reported for a wide variety of systems and, as it looks like, depends on >> the default BIOS setup - means it's hard to

[Xen-devel] [PATCH v3] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

should help in case of post boot CPU onlining. Although we're running watchdog at much lower frequency it's neveretheless possible we may trigger the issue anyway. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v3: corrected comments and coommit meesage. --- xen/arch/x86/

[Xen-devel] [PATCH v2] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- xen/arch/x86/apic.c| 2 +- xen/arch/x86/smpboot.c | 3 +++ xen/arch/x86/traps.c | 9 +++-- 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c index 5039173..ffa5a69 100644 ---

[Xen-devel] [PATCH v4] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

also help in case of post boot CPU onlining. Although we're running watchdog at much lower frequency at this point, it's neveretheless possible we may trigger the issue anyway. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v4: make comments and commit message even more accura

[Xen-devel] [PATCH] x86/kexec: harden kexec path by entering with NMIs latched

interrupts that should unlatch NMIs as soon as the first interrupt comes. Signed-off-by: Igor Druzhinin --- xen/arch/x86/crash.c | 69 xen/arch/x86/machine_kexec.c | 38 ++-- xen/include/asm-x86/apic.h | 1 + 3 files

[Xen-devel] [PATCH] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

This should help to avoid problems with accessing the device after migration/resume without PV drivers. Older systems will acquire the new record when migrated which should not change their state for worse. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen_pvde

[Xen-devel] [PATCH v2] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

region to fail. PV tools enable some logic to save and restore PCI configuration state from within the VM every time it migrates which basically hides the issue. Older systems will acquire the new record when migrated which should not change their state for worse. Signed-off-by: Igor Druzhinin

[Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

that the original patch tried to workaround (uneven number of region_add/del calls on device attach/detach) was fixed in later QEMU versions. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reported-by: Ross Lagerwall <ross.lagerw...@citrix.com> --- hw/xen/xen_pt.c | 2 +- 1 fil

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

On 17/04/18 15:15, Anthony PERARD wrote: > On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: >> Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced >> a subtle bug. As soon as the guest switches off Bus Mastering on the >> device it immediatel

[Xen-devel] [PATCH v2] xen/pt: use address_space_memory object for memory region hooks

that the original patch tried to workaround (uneven number of region_add/del calls on device attach/detach) was fixed in d25836cafd (memory: do explicit cleanup when remove listeners). Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reported-by: Ross Lagerwall <ross.lagerw...@citrix.c

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

ping? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/pt: use address_space_memory object for memory region hooks

On 17/04/18 15:15, Anthony PERARD wrote: > On Fri, Apr 06, 2018 at 10:21:23PM +0100, Igor Druzhinin wrote: >> Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced >> a subtle bug. As soon as the guest switches off Bus Mastering on the >> device it immediatel

[Xen-devel] [PATCH] xen/hvm: correct reporting of modified memory under physmap during migration

there is no way to access physmap properly inside xen_hvm_modified_memory() let's make it a global structure. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 37 +++-- hw/i386/xen/xen-mapcache.c| 2 +- include/

Re: [Xen-devel] [PATCH 1/3] x86/HVM: __hvm_copy() should not write to p2m_ioreq_server pages

wrong for the >> p2m_ioreq_server special case. That change widened a pre-existing issue >> though: Other writes to such pages also need to be failed (or forced >> through emulation), in particular hypercall buffer writes. >> >> Reported-by: ??? >

Re: [Xen-devel] [PATCH 4/3] x86/HVM: hvm_map_guest_frame_rw() should respect p2m_ioreq_server

On 13/11/2018 10:46, Jan Beulich wrote: > Writes to such pages would need to be handed to the emulator, which we're > not prepared to do at this point. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -2556,7 +2556,8 @@ static void

Re: [Xen-devel] [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE

On 20/12/2017 14:05, Boris Ostrovsky wrote: > Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum > reservation") left host memory not assigned to dom0 as available for > memory hotplug. > > Unfortunately this also meant that those regions could be used by > others. Specifically,

Re: [Xen-devel] [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE

On 27/11/2018 03:28, Boris Ostrovsky wrote: > On 11/26/18 2:57 PM, Igor Druzhinin wrote: >> On 26/11/2018 19:42, Boris Ostrovsky wrote: >>> On 11/26/18 12:10 PM, Igor Druzhinin wrote: >>>> On 26/11/2018 16:25, Boris Ostrovsky wrote: >>>>> On 11/25/18 8

[Xen-devel] [PATCH] Revert "xen/balloon: Mark unallocated host memory as UNUSABLE"

o got amended by the following 03a551734 ("x86/PCI: Move and shrink AMD 64-bit window to avoid conflict") which made the original fix to Xen ballooning unnecessary. Signed-off-by: Igor Druzhinin --- In mail thread [1] it was agreed to revert the change due to technical comlications of fixin

Re: [Xen-devel] [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE

On 26/11/2018 19:42, Boris Ostrovsky wrote: > On 11/26/18 12:10 PM, Igor Druzhinin wrote: >> On 26/11/2018 16:25, Boris Ostrovsky wrote: >>> On 11/25/18 8:00 PM, Igor Druzhinin wrote: >>>> On 20/12/2017 14:05, Boris Ostrovsky wrote: >>>>> Commit f577

Re: [Xen-devel] [PATCH v3] xen/balloon: Mark unallocated host memory as UNUSABLE

On 26/11/2018 16:25, Boris Ostrovsky wrote: > On 11/25/18 8:00 PM, Igor Druzhinin wrote: >> On 20/12/2017 14:05, Boris Ostrovsky wrote: >>> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum >>> reservation") left host memory not assigne

Re: [Xen-devel] [PATCH v2 ] always clear the X2APIC_ENABLE bit for PV guest

> always clear the X2APIC_ENABLE bit. > > Signed-off-by: Talons Lee > Reviewed-by: Juergen Gross > > --- > CC: Igor Druzhinin > CC: Sergey Dyasli > CC: Andrew Cooper > CC: Juergen Gross > > v2: > don't use fake cpuid to cheat xen_read_msr_safe(), j

Re: [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

On 24/03/2019 03:50, Roger Pau Monné wrote: > On Fri, Mar 22, 2019 at 10:06:45AM +0100, Laszlo Ersek wrote: >> The core PciBusDxe driver that is built into OVMF certainly does the >> resource allocation/placement, but when OVMF is executed on Xen, this >> functionality of PciBusDxe is dynamically

[Xen-devel] [PATCH] x86/vmx: Fixup removals from MSR load-lists

immediate guest failure. Signed-off-by: Igor Druzhinin --- I assume this is a candidate for backporting to stable-4.12. --- xen/arch/x86/hvm/vmx/vmcs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 74f2a0

[Xen-devel] [PATCH v2] x86/vmx: Fixup removals of MSR load/save list entries

t failure. Reviewed-by: Andrew Cooper Reviewed-by: Jan Beulich Signed-off-by: Igor Druzhinin --- Changes in v2: * better commit description as suggested --- xen/arch/x86/hvm/vmx/vmcs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arc

Re: [Xen-devel] [BUG] pci: mixed allocation pf and non-pf PCI MEM BAR (OVMF crash)

On 01/04/2019 19:48, Martin Cerveny wrote: > Hello. > > On Mon, 1 Apr 2019, Jan Beulich wrote: > On 31.03.19 at 10:11, wrote: >>> There is problem in PCI device allocation algorithm (pci_setup()). >>> Algorithm allocates PCI BAR sorted by size and this allows >>> mixed allocation of

[Xen-devel] [PATCH] tools/xl: use libxl_domain_info to get domain type for vcpu-pin

Parsing the config seems to be an overkill for this particular task and the config might simply be absent. Type returned should be either LIBXL_DOMAIN_TYPE_HVM or LIBXL_DOMAIN_TYPE_PV but in that context distinction between PVH and HVM should be irrelevant. Signed-off-by: Igor Druzhinin

[Xen-devel] [PATCH] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

. Fortunately, we can use the actual MSB, which is usually higher than the currently hardcoded 32, and treat this case correctly at least on modern hardware. Signed-off-by: Igor Druzhinin --- xen/arch/x86/nmi.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86

[Xen-devel] [PATCH v2] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

. Fortunately, we can use the actual MSB, which is usually higher than the currently hardcoded 32, and treat this case correctly at least on modern hardware. Signed-off-by: Igor Druzhinin --- Changes in v2: * taken care of the case where leaf 0xa is missing or width is 0 * apply a cap in case width

Re: [Xen-devel] [PATCH v2] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

On 26/02/2019 14:58, Jan Beulich wrote: >>>> On 26.02.19 at 14:25, wrote: >> On 26/02/2019 13:12, Igor Druzhinin wrote: >> >>> @@ -323,6 +327,10 @@ static void setup_p6_watchdog(unsigned counter) >>> unsigned int evntsel; >>

[Xen-devel] [PATCH v3] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

. Fortunately, we can use the actual MSB, which is usually higher than the currently hardcoded 32, and treat this case correctly at least on modern hardware. Signed-off-by: Igor Druzhinin --- Changes in v3: * counter clipping dropped since v2 * instead high and low capping is applied at setup time

Re: [Xen-devel] [PATCH v2] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

On 26/02/2019 13:12, Igor Druzhinin wrote: > The logic currently tries to work out if a recent overflow (that indicates > that NMI comes from the watchdog) happened by checking MSB of performance > counter MSR that is initially sign extended from a negative value > tha

Re: [Xen-devel] [PATCH v2] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

On 26/02/2019 14:56, Jan Beulich wrote: >>>> On 26.02.19 at 14:33, wrote: >> On 26/02/2019 13:12, Igor Druzhinin wrote: >>> @@ -292,6 +295,7 @@ static inline void write_watchdog_counter(const char >>> *descr) >>> u64 count = (u64)cpu_kh

Re: [Xen-devel] [PATCH v2] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

On 26/02/2019 13:25, Andrew Cooper wrote: > On 26/02/2019 13:12, Igor Druzhinin wrote: > >> @@ -323,6 +327,10 @@ static void setup_p6_watchdog(unsigned counter) >> unsigned int evntsel; >> >> nmi_perfctr_msr = MSR_P6_PERFCTR(0); >> +if (

[Xen-devel] [PATCH v2] xen-netback: fix occasional leak of grant ref mappings under memory pressure

ic to deal with frag_list deallocation in a single place. Signed-off-by: Paul Durrant Signed-off-by: Igor Druzhinin --- drivers/net/xen-netback/netback.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netba

Re: [Xen-devel] [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure

On 28/02/2019 11:21, Paul Durrant wrote: >>> @@ -1153,6 +1152,10 @@ static int xenvif_tx_submit(struct xenvif_queue >>> *queue) >>> kfree_skb(skb); >>> continue; >>> } >>> + >>> + /*

[Xen-devel] [PATCH] xen-netback: don't populate the hash cache on XenBus disconnect

. In order to avoid this we prevent hashing of those packets if there are no queues initialized. In that case RCU protection of queues guards the hash cache as well. Signed-off-by: Igor Druzhinin --- Found this while applying the previous patch to our patchqueue. Seems it never went to the mailing

Re: [Xen-devel] [PATCH v4] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

On 27/02/2019 10:02, Jan Beulich wrote: > > Reviewed-by: Jan Beulich > albeit ... > >> @@ -323,6 +326,15 @@ static void setup_p6_watchdog(unsigned counter) >> unsigned int evntsel; >> >> nmi_perfctr_msr = MSR_P6_PERFCTR(0); >> +if ( !nmi_p6_event_width ) >> +

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

our case) - so it's >> currently normal to keep IOMMU enabled. It would only require to change >> crash kernel command line by enabling IOMMU drivers from the existing users. >> >> An option is left for compatibility with ancient crash kernels which >> didn't like to ha

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 19/02/2019 07:43, Jan Beulich wrote: >>>> On 18.02.19 at 19:30, wrote: >> On 18/02/2019 16:21, Igor Druzhinin wrote: >>> It's unsafe to disable IOMMU on a live system which is the case >>> if we're crashing since remapping hardware doesn't usually

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 08:48, Jan Beulich wrote: > > Some entity needs to decide whether to add the respective command > line option to the crash kernel's command line. It should be this same > entity to tell Xen whether to keep the IOMMU enabled while invoking > the crash kernel. I am merely guessing

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 09:01, Jan Beulich wrote: > But isn't it a valid question whether keeping interrupt remapping > enabled is helpful or potentially making things worse? The > description of the patch discusses the DMA translation aspects > only. Unless the crash kernel would always operate in polling

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 08:55, Jan Beulich wrote: > > Everything, absolutely everything is possible as a cause for a crash. > I don't see why device isolation would matter here at all. Page table > corruption (be it IOMMU or CPU one) can be caused by > malfunctioning kernel code, entirely unrelated to what

[Xen-devel] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

it by disabling PCI address decoding explicitly before the first attempt to size BARs on Xen. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 +++ 1 file changed, 34 insertions(+) diff

[Xen-devel] [PATCH RESEND 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64

In case BAR64 is placed below 4G choose the correct aperture. This fixes a failed assertion down the code path. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +- 1 file changed, 5 insertions(+), 1

[Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c index 9204179..c23c46d 100644 --- a/OvmfPkg

[Xen-devel] [PATCH RESEND 0/3] Xen PCI passthrough fixes

Resend to include xen-devel@lists.xenproject.org to CC Igor Druzhinin (3): OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64 OvmfPkg/XenSupport: turn off address decoding before BAR sizing

Re: [Xen-devel] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 06/03/2019 13:22, Laszlo Ersek wrote: > On 03/06/19 13:40, Igor Druzhinin wrote: >> On Xen, hvmloader firmware leaves address decoding enabled for >> enumerated PCI device before jumping into OVMF. OVMF seems to >> expect it to be disabled and tries to size PCI BARs in seve

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 09:52, Jan Beulich wrote: On 20.02.19 at 19:19, wrote: >> On 20/02/2019 08:48, Jan Beulich wrote: >>> >>> Some entity needs to decide whether to add the respective command >>> line option to the crash kernel's command line. It should be this same >>> entity to tell Xen whether

Re: [Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 12:34, Jan Beulich wrote: On 21.02.19 at 23:08, wrote: >> Modern Linux kernels taught to copy all the necessary DMAR/IR tables >> following kexec from the previous kernel (Xen in our case) - so it's >> currently normal to keep IOMMU enabled. It might require minor changes to >>

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 22/02/2019 12:51, Jan Beulich wrote: On 22.02.19 at 13:40, wrote: >> There are several reasons why it's better: >> a) kernel is able to perform device reset properly as it has bus >> specific code that does this. There is even a comment in the code >> mentioning that at the moment it

[Xen-devel] [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure

as the slots get reused for new mappings. That behavior is observed under certain workloads where sudden spikes of page cache usage for writes coexist with active atomic skb allocations. Signed-off-by: Igor Druzhinin --- drivers/net/xen-netback/netback.c | 3 +++ 1 file changed, 3 insertions(+) diff

[Xen-devel] [PATCH v4] x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

. Fortunately, we can use the actual MSB, which is usually higher than the currently hardcoded 32, and treat this case correctly at least on modern hardware. Signed-off-by: Igor Druzhinin --- Changes in v4: * add special handling for zero-field case which is identical to max-leaf-too-small case

[Xen-devel] [PATCH v2] iommu: leave IOMMU enabled by default during kexec crash transition

with ancient crash kernels which didn't like to have IOMMU active under their feet on boot. Signed-off-by: Igor Druzhinin --- Changes in v2: * Fixed and clarified documentation * Renamed option to crash-disable * Other minor suggestions taken --- docs/misc/xen-command-line.pandoc | 8

Re: [Xen-devel] Commit 331b51 breaks live migration on FreeBSD/Xen dom0

On 14/03/2019 15:54, Roger Pau Monné wrote: > The log of the incoming QEMU is: > > qemu-system-i386: -serial pty: char device redirected to /dev/pts/4 (label > serial0) > xen: shared page at pfn feff0 > xen: buffered io page at pfn feff1 > xen: buffered io evtchn is 4 > xen_mapcache:

[Xen-devel] [PATCH v4 2/2] x86/hvm: finish IOREQs correctly on completion path

of emulation but leaves a case where new IOREQs might be introduced by P2M changes from RAM to MMIO (which is less likely to find in practice) that requires more substantial changes in MMIO emulation code. Reviewed-by: Paul Durrant Signed-off-by: Igor Druzhinin --- Changes in v4: * corrected the cases

[Xen-devel] [PATCH v4 1/2] x86/hvm: split all linear reads and writes at page boundary

Signed-off-by: Igor Druzhinin --- xen/arch/x86/hvm/emulate.c | 70 +- 1 file changed, 38 insertions(+), 32 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index 754baf6..c236e7d 100644 --- a/xen/arch/x86/hvm/emulate.c

Re: [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

On 14/03/2019 17:41, Anthony PERARD wrote: > Hi, > > On Wed, Mar 06, 2019 at 12:40:54PM +0000, Igor Druzhinin wrote: >> This aperture doesn't exist in OVMF and trying to use it causes > > I'm trying to understand what you mean by writing "doesn't exist in >

Re: [Xen-devel] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 14/03/2019 17:55, Anthony PERARD wrote: > On Wed, Mar 06, 2019 at 12:40:56PM +0000, Igor Druzhinin wrote: >> On Xen, hvmloader firmware leaves address decoding enabled for >> enumerated PCI device before jumping into OVMF. OVMF seems to >> expect it to be disabled and t

Re: [Xen-devel] XenGT is still regressed on master

On 11/03/2019 07:14, Juergen Gross wrote: > Any estimate when we can expect patches? The 4.12 release is pending and > this is the only remaining regression I'm aware of. > > If you tell me there is no reasonable chance of anything acceptable > being posted this week I'd go on with the release

Re: [Xen-devel] [PATCH v2] x86/hvm: finish IOREQ correctly on completion path

On 13/03/2019 08:53, Jan Beulich wrote: On 12.03.19 at 17:23, wrote: >> Since the introduction of linear_{read,write}() helpers in 3bdec530a5 >> (x86/HVM: split page straddling emulated accesses in more cases) the >> completion path for IOREQs has been broken: if there is an IOREQ in >>

[Xen-devel] XenGT is still regressed on master

Jan, We've noticed that there is still a regression with p2m_ioreq_server P2M type on master. Since the commit 940faf0279 (x86/HVM: split page straddling emulated accesses in more cases) the behavior of write and rmw instruction emulation changed (possibly unintentionally) so that it might not

Re: [Xen-devel] XenGT is still regressed on master

On 08/03/2019 14:58, Jan Beulich wrote: On 08.03.19 at 15:25, wrote: >> On 08/03/2019 11:55, Jan Beulich wrote: >> >> I like the latter suggestion more. Seems less invasive and prone to >> regressions. I'd like to try to implement it. Although I think the >> hypervisor check should be more

Re: [Xen-devel] XenGT is still regressed on master

On 08/03/2019 11:55, Jan Beulich wrote: > If so, my first reaction is to blame the kernel module: > Machine state (of the VM) may not change while processing > a write, other than to carry out the _direct_ effects of the write. I > don't think a p2m type change is supposed to be occurring as a

[Xen-devel] [PATCH] x86/hvm: finish IOREQ correctly on completion path

where e.g. an emulator balloons memory to/from the guest in response to MMIO read/write, etc. Fix it by checking if IOREQ completion is required before trying to finish a memory access immediately through hvm_copy_..(), re-enter hvmemul_do_io() otherwise. Signed-off-by: Igor Druzhinin --- xen

Re: [Xen-devel] XenGT is still regressed on master

On 08/03/2019 16:14, Jan Beulich wrote: On 08.03.19 at 16:18, wrote: >> On 08/03/2019 14:58, Jan Beulich wrote: >> On 08.03.19 at 15:25, wrote: On 08/03/2019 11:55, Jan Beulich wrote: I like the latter suggestion more. Seems less invasive and prone to regressions.

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

been created at the requested address. > > Also note that at least on FreeBSD using MAP_FIXED will cause mmap to > try harder to honor the passed address. > > Signed-off-by: Roger Pau Monné > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paul Durrant > Cc:

Re: [Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

been created at the requested address. > > Also note that at least on FreeBSD using MAP_FIXED will cause mmap to > try harder to honor the passed address. > > Signed-off-by: Roger Pau Monné > Reviewed-by: Paul Durrant > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc

[Xen-devel] [PATCH v2] x86/hvm: finish IOREQ correctly on completion path

where e.g. an emulator balloons memory to/from the guest in response to MMIO read/write, etc. Fix it by checking if IOREQ completion is required before trying to finish a memory access immediately through hvm_copy_..(), re-enter hvmemul_do_io() otherwise. Signed-off-by: Igor Druzhinin --- Changes

Re: [Xen-devel] [PATCH] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On 15/03/2019 18:38, Anthony PERARD wrote: > On Fri, Mar 15, 2019 at 06:14:09PM +, Anthony PERARD wrote: >> On Fri, Mar 15, 2019 at 09:58:47AM +0100, Roger Pau Monne wrote: >>> Or if it's not possible to honor the hinted address an error is returned >>> instead. This makes it easier to spot

[Xen-devel] [PATCH v3 1/2] x86/hvm: split all linear reads and writes at page boundary

Ruling out page straddling at linear level makes it easier to distinguish chunks that require proper handling as MMIO access and not complete them as page straddling memory transactions prematurely. This doesn't change the general behavior. Signed-off-by: Igor Druzhinin --- Changes in v3: * new

Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely

d), and turning off all IOMMU functionality in this > case is entirely unhelpful behaviour. > > Leave the warning which identifies the problematic devices, but drop the > remaining logic. This leaves the system in better overall state, and working > in the same way that it did in previou

Re: [Xen-devel] [PATCH] VT-d/DMAR: accept DRHD with non-discoverable PCI devices

On 21/03/2019 13:17, Andrew Cooper wrote: > On 20/03/2019 20:22, Igor Druzhinin wrote: >> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call >> before calling acpi_parse_dmar()") PCI segment 0 is now known early >> which made the sanity check on DR

[Xen-devel] [PATCH] VT-d/DMAR: accept DRHD with non-discoverable PCI devices

llow error reporting. Signed-off-by: Igor Druzhinin --- docs/misc/xen-command-line.pandoc | 2 +- xen/drivers/passthrough/iommu.c| 2 +- xen/drivers/passthrough/vtd/dmar.c | 25 ++--- 3 files changed, 8 insertions(+), 21 deletions(-) diff --git a/docs/misc/xen-command-line

[Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

-by: Igor Druzhinin --- Jan, Andrew, should we have this option here and, if so, what is the default value for it should be? --- docs/misc/xen-command-line.pandoc | 5 + xen/arch/x86/crash.c | 5 +++-- xen/drivers/passthrough/iommu.c | 6 ++ 3 files changed, 14 insertions(+), 2

[Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

it by disabling PCI address decoding explicitly before the first attempt to size BARs on Xen. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Igor Druzhinin --- Changes in v2: * coding style issues and minor suggestions --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 35

[Xen-devel] [PATCH v2 0/3] Xen PCI passthrough fixes

Igor Druzhinin (3): OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64 OvmfPkg/XenSupport: turn off address decoding before BAR sizing OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 44

[Xen-devel] [PATCH v2 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64

In case BAR64 is placed below 4G choose the correct aperture. This fixes a failed assertion down the code path. Contributed-under: TianoCore Contribution Agreement 1.1 Acked-by: Anthony PERARD Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +- 1 file

[Xen-devel] [PATCH v2 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

to pass additional allocation flags as we set ResourceAssigned flag on the root bridge which means they will be ignored. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Igor Druzhinin --- Changes in v2: * remove usage of prefetchable aperture entirely * explained rationale

Re: [Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 11/04/2019 14:19, Andrew Cooper wrote: > On 09/04/2019 04:12, Igor Druzhinin wrote: >> On Xen, hvmloader firmware leaves address decoding enabled for >> enumerated PCI device before jumping into OVMF. OVMF seems to >> expect it to be disabled and tries to size PCI B

Re: [Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 11/04/2019 15:13, Igor Druzhinin wrote: > On 11/04/2019 14:19, Andrew Cooper wrote: >> On 09/04/2019 04:12, Igor Druzhinin wrote: >>> On Xen, hvmloader firmware leaves address decoding enabled for >>> enumerated PCI device before jumping into OVMF. OVMF seems to &

Re: [Xen-devel] [PATCH v3 2/2] x86/hvm: finish IOREQs correctly on completion path

On 15/03/2019 12:27, Jan Beulich wrote: On 14.03.19 at 23:30, wrote: >> Since the introduction of linear_{read,write}() helpers in 3bdec530a5 >> (x86/HVM: split page straddling emulated accesses in more cases) the >> completion path for IOREQs has been broken: if there is an IOREQ in >>

[Xen-devel] [PATCH] libacpi: report PCI slots as enabled only for hotpluggable devices

of its PCI hotplug controller. qemu-xen has similar capability that reports if device is "hotpluggable or absent" which we can use to achieve the same result. Signed-off-by: Igor Druzhinin --- tools/libacpi/mk_dsdt.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --g

[Xen-devel] [PATCH] x86/cpuid: leak OSXSAVE only when XSAVE is not clear in policy

will lead to guest crash early in boot. Signed-off-by: Igor Druzhinin --- xen/arch/x86/cpuid.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index ac7026f..510a038 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c

[Xen-devel] [PATCH] x86/mtrr: recalculate P2M type for domains with iocaps

This change reflects the logic in epte_get_entry_emt() and allows changes in guest MTTRs to be reflected in EPT for domains having direct access to certain hardware memory regions but without IOMMU context assigned (e.g. XenGT). Signed-off-by: Igor Druzhinin --- xen/arch/x86/hvm/mtrr.c | 2

[Xen-devel] [PATCH v2] tools/xl: use libxl_domain_info to get domain type for vcpu-pin

-by: Igor Druzhinin --- tools/xl/xl_vcpu.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/tools/xl/xl_vcpu.c b/tools/xl/xl_vcpu.c index 71d3a5c..93abcc6 100644 --- a/tools/xl/xl_vcpu.c +++ b/tools/xl/xl_vcpu.c @@ -79,7 +79,6 @@ void apply_global_affinity_masks

Re: [Xen-devel] [PATCH] x86/mtrr: recalculate P2M type for domains with iocaps

s but without IOMMU >> context assigned (e.g. XenGT). >> >> Signed-off-by: Igor Druzhinin > > Fundamentally I'm happy to get both in sync, so > Reviewed-by: Jan Beulich > > But I have a question: > >> void memory_type_changed(stru

[Xen-devel] [PATCH v3 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

to pass additional allocation flags as we set ResourceAssigned flag on the root bridge which means they will be ignored. Reviewed-by: Anthony PERARD Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 ++- 1 file changed, 12 insertions

[Xen-devel] [PATCH v3 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64

In case BAR64 is placed below 4G choose the correct aperture. This fixes a failed assertion down the code path. Acked-by: Anthony PERARD Signed-off-by: Igor Druzhinin --- OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH 0/3] Xen PCI passthrough fixes

Igor Druzhinin (3): OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64 OvmfPkg/XenSupport: turn off address decoding before BAR sizing OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 53

[Xen-devel] [PATCH v3 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

it by disabling PCI address decoding explicitly before the first attempt to size BARs on Xen. Signed-off-by: Igor Druzhinin --- Changes in v3: - dropped unused arguments and rename PcatPciRootBridgeDecoding function - make mask application more clear as suggested --- OvmfPkg/Library/PciHostBridgeLib

Re: [Xen-devel] [PATCH] x86/mtrr: recalculate P2M type for domains with iocaps

On 25/04/2019 16:49, Jan Beulich wrote: On 25.04.19 at 16:50, wrote: >> On 25/04/2019 14:30, Jan Beulich wrote: >> On 23.04.19 at 13:37, wrote: void memory_type_changed(struct domain *d) { -if ( has_iommu_pt(d) && d->vcpu && d->vcpu[0] ) +if (

[Xen-devel] [PATCH] tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored

C version of xenstored had this ability since 61aaed0d5 ("Allow XS_INTRODUCE to be used for rebinding the xenstore evtchn.") from 2007. Copy it as is to Ocaml version. Signed-off-by: Igor Druzhinin --- tools/ocaml/xenstored/domain.ml | 6 +- tools/ocaml/xenstored/process.ml | 8 +

  1   2   3   4   >