izing). There are
no convenient hooks for us to subscribe to so try to register MCFG
areas earlier upon the first invocation of xen_add_device(). Keep the
existing initcall in case information of MCFG areas is updated later
in acpi_init().
Signed-off-by: Igor Druzhinin
---
drivers/xen/pci.c | 15 +++
On 04/09/2019 10:08, Jan Beulich wrote:
> On 04.09.2019 02:20, Igor Druzhinin wrote:
>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>> a reserved resource in DSDT. Having i
On 06/09/2019 23:30, Boris Ostrovsky wrote:
> On 9/3/19 8:20 PM, Igor Druzhinin wrote:
>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>> a reserved resource in DSDT. Havin
On 08/09/2019 19:28, Boris Ostrovsky wrote:
> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>
>> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>>>
>>> Where is MCFG parsed? pci_arch_init()?
>>>> It happens twice:
>> 1) first time early one in p
On 09/09/2019 00:30, Boris Ostrovsky wrote:
> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>>> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>>> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>>>>> Where is MCFG par
On 09/09/2019 20:19, Boris Ostrovsky wrote:
> On 9/8/19 7:37 PM, Igor Druzhinin wrote:
>> On 09/09/2019 00:30, Boris Ostrovsky wrote:
>>> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>>>> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>>>>> On 9/6/19 7:00 PM,
On 10/09/2019 02:47, Boris Ostrovsky wrote:
> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>> On 09/09/2019 20:19, Boris Ostrovsky wrote:
>>> On 9/8/19 7:37 PM, Igor Druzhinin wrote:
>>>> On 09/09/2019 00:30, Boris Ostrovsky wrote:
>>>>> On 9/8/19 5:11 PM,
On 10/09/2019 10:55, Jan Beulich wrote:
> On 10.09.2019 11:46, Igor Druzhinin wrote:
>> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>>> Actually, pci_mmcfg_late_init() that's called out of acpi_init() -
>>>
On 10/09/2019 18:48, Boris Ostrovsky wrote:
> On 9/10/19 5:46 AM, Igor Druzhinin wrote:
>> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>>> On 09/09/2019 20:19, Boris Ostrovsky wrote:
>>>>
>>>>&
On 10/09/2019 22:19, Boris Ostrovsky wrote:
> On 9/10/19 4:36 PM, Igor Druzhinin wrote:
>> On 10/09/2019 18:48, Boris Ostrovsky wrote:
>>> On 9/10/19 5:46 AM, Igor Druzhinin wrote:
>>>> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>>>>> On 9/9/19 5:48 P
F BAR sizing). There are
no convenient hooks for us to subscribe to so register MCFG areas earlier
upon the first invocation of xen_add_device(). It should be safe to do once
since all the boot time buses must have their MCFG areas in MCFG table
already and we don't support PCI bus hot-p
On 24/09/2019 18:29, Dario Faggioli wrote:
> On Tue, 2019-09-24 at 12:15 +0100, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> After an extensive testing of your jgross1/sched-v3 branch in XenRT,
>> I'm happy to say that we've found no functional regressions so far
>> when running in the default (thread
h querying 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(-)
; 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
Device model is supposed to destroy IOREQ server for itself.
Signed-off-by: Igor Druzhinin
---
hw/i386/xen/xen-hvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index e8e79e0..30a5948 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen
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 +
he hashtable indexed by domid is not the same as
connection that we got XS_INTRODUCE message from. (see
tools/xenstore/xenstrored_domain.c)
Igor
>> On 19 Aug 2019, at 19:45, Igor Druzhinin wrote:
>>
>> C version of xenstored had this ability since 61aaed0d5 ("Allow
>>
On 20/08/2019 13:11, Christian Lindig wrote:
>
>
>> On 20 Aug 2019, at 11:45, Igor Druzhinin wrote:
>>
>> On 20/08/2019 09:21, Christian Lindig wrote:
>>>> + if (Domain.get_mfn edom) = mfn &&
>>>> (Connections.find_doma
d PTs enabled.
While here fixup compat M2P entries as well.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/x86_64/mm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 1919cae..a741d4e 100644
--- a/xen/arch/x86/x86_64
Xen to use MCFG area even it's not properly
reserved in E820.
Signed-off-by: Igor Druzhinin
---
I think we need to have this option to at least have a way to workaround
problem (1). Problem (2) could be solved in Dom0 kernel by invoking
xen_mcfg_late() earlier but before the first PCI bus en
there are IOREQ servers left behind, a new QEMU instance will
override its ranges anyway.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/domain.c | 2 --
xen/arch/x86/hvm/hvm.c| 5 -
xen/include/asm-x86/hvm/hvm.h | 1 -
3 files changed, 8 deletions(-)
diff --git a/xen/arch/x86
On 29/08/2019 09:00, Roger Pau Monné wrote:
>>
>> I think we need to have this option to at least have a way to workaround
>> problem (1). Problem (2) could be solved in Dom0 kernel by invoking
>> xen_mcfg_late() earlier but before the first PCI bus enumertaion which
>> currently happens somwhere d
should be able to work as
even if there are IOREQ servers left behind, a new QEMU instance will
override its ranges anyway.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/domain.c | 2 --
xen/arch/x86/hvm/hvm.c| 5 -
xen/include/asm-x86/hvm/hvm.h | 1 -
3 files changed, 8 dele
r feet on boot.
Signed-off-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 file
ious kernel (Xen in 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
&
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&
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 that
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
>
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
s still left for compatibility 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
---
do
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 t
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
>>
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 disab
ously.
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/arc
ously.
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
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
> that we prog
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 (
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
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;
>>>
>&g
ously.
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
ously.
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
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 )
>> +nmi_p6_ev
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
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;
>>> }
>>> +
>>> + /* Copie
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
.
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
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
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
t 1.1
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/Ov
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
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
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-
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 side
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 ge
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. I'd
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
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 pro
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
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
>> progr
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_map_cach
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 e
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 trie
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:
enough for a more general case where machine state
arbitrarely changes behind our back.
Signed-off-by: Igor Druzhinin
---
Changes in v3:
* made it more clear that it's still a partial fix in the commit description
* other minor suggestions
---
xen/arch/x86/hvm/emulate.c
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
>> progr
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 the
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
ulich
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/emul
en 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
>
en 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
&g
ill allow 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
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
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 previous r
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 d
lmost 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 7
est 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/xe
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 prefetcha
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
s not necessary 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
* expl
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
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
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
: 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
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
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
>&
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
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(struct domain
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 ( (has_iommu_pt(
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
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
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 a
s not necessary 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
logging in iommu_do_pci_domctl() to be
removed.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
---
Since Paul doesn't mind and kindly agreed - I'm taking ownership of this patch
review process from now on.
Changes in v3:
- Dropped controversial hunk with error code pro
On 18/11/2019 11:21, Jan Beulich wrote:
> On 15.11.2019 19:59, Igor Druzhinin wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -932,30 +932,26 @@ static int deassign_device(struct domain *d, uint16_t
>> seg, uint8_t
On 12/11/2019 11:38, Dietmar Hahn wrote:
> Hi,
>
> on a new machine with cpu Intel(R) Xeon(R) Gold 6242 CPU the kexec/kdump
> doesn't work with current xen-4.13.0-rc.
> The last output of the xen console is:
>
> (XEN) Hardware Dom0 crashed: Executing kexec image on cpu5
> (XEN) Shot down all CPUs
On 20/11/2019 15:49, Jürgen Groß wrote:
> On 15.11.19 19:59, Igor Druzhinin wrote:
>> From: Paul Durrant
>>
>> Dropping the pcidevs lock between calling device_assigned() and
>> assign_device() means that the latter has to do the same check as the
>> former for
On 14/11/2019 12:28, Igor Druzhinin wrote:
> On 13/11/2019 13:50, Jan Beulich wrote:
>> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
>> allocation") moved ourselves into a more secure default state, but
>> didn't take sufficient care to
On 14/11/2019 12:28, Igor Druzhinin wrote:
> On 13/11/2019 13:50, Jan Beulich wrote:
>> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
>> allocation") moved ourselves into a more secure default state, but
>> didn't take sufficient care to
IV bit shouldn't be set in DTE if interrupt remapping is not
enabled. This was traced to be a root cause behind assertion in
interrupt handling code on Lisbon.
Signed-off-by: Igor Druzhinin
---
xen/drivers/passthrough/amd/iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 26/11/2019 14:14, Jan Beulich wrote:
> On 26.11.2019 13:25, Andrew Cooper wrote:
>> On 26/11/2019 08:42, Jan Beulich wrote:
>>> On 25.11.2019 22:05, Igor Druzhinin wrote:
>>>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>>>> +++ b/xen/drivers/pa
1 - 100 of 355 matches
Mail list logo
