Hi all,
Thank you for the reply.
I checked with xen version 4.9, Still the error for the filesystem
persists. What seems to be the problem?. I am attaching the log for the
above error and also the dts file I am using.
Regards,
George
NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9
This run is configured for baseline tests only.
flight 71961 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71961/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 20 capture-logs(2
flight 71962 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71962/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
Hello George,
On 11.08.17 10:16, George John wrote:
I checked with xen version 4.9, Still the error for the filesystem
persists. What seems to be the problem?. I am attaching the log for
the above error and also the dts file I am using.
I've looked through the log and it is the same as on my t
On 08/08/17 16:00, Boris Ostrovsky wrote:
> On 08/08/2017 02:46 AM, Juergen Gross wrote:
>> On 28/07/17 12:23, Juergen Gross wrote:
>>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
>>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
>>> of __va() before
>>> On 10.08.17 at 19:04, wrote:
> On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne 06/30/17 5:01 PM >>>
>> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const
>> >struct vpci_bar *bar,
>> >if ( IS_ERR(mem) )
>> >return -PTR_ERR(mem);
>> >
On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote:
> >>> On 10.08.17 at 19:04, wrote:
> > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
> >> >>> Roger Pau Monne 06/30/17 5:01 PM >>>
> >> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const
> >> >struc
>>> On 10.08.17 at 19:22, wrote:
> --- a/xen/include/asm-x86/xenoprof.h
> +++ b/xen/include/asm-x86/xenoprof.h
> @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);
>
> #else
>
> +struct vcpu;
There already is a forward declaration in this header - I'd suggest
moving that one up (
On Fri, Aug 11, 2017 at 04:15:59AM -0600, Jan Beulich wrote:
> >>> On 10.08.17 at 19:22, wrote:
> > --- a/xen/include/asm-x86/xenoprof.h
> > +++ b/xen/include/asm-x86/xenoprof.h
> > @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);
> >
> > #else
> >
> > +struct vcpu;
>
> There a
Hi,
On 11/08/17 05:54, Manish Jaggi wrote:
On 8/10/2017 6:44 PM, Julien Grall wrote:
On 08/10/2017 02:00 PM, Manish Jaggi wrote:
HI Julien,
On 8/10/2017 5:43 PM, Julien Grall wrote:
On 10/08/17 13:00, Manish Jaggi wrote:
Hi Julien,
On 8/10/2017 4:58 PM, Julien Grall wrote:
On 10/0
>>> On 11.08.17 at 12:11, wrote:
> On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote:
>> >>> On 10.08.17 at 19:04, wrote:
>> > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
>> >> >>> Roger Pau Monne 06/30/17 5:01 PM >>>
>> >> >+case PCI_MSIX_ENTRY_DATA_OFFSET:
>> >>
Hi Wei,
On 10/08/17 18:22, Wei Liu wrote:
They don't belong there. Removing them causes build errors in several
places. Add the forward declarations in those places.
Signed-off-by: Wei Liu
For ARM:
reviewed-by: Julien Grall
Cheers,
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jacks
flight 112585 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112585/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7
baseline version:
ovmf 7ef0dae092afcfb6fab7e
Hi Volodymyr,
On 10/08/17 22:09, Julien Grall wrote:
We can stick to XEN-only approach, like XENFEAT_* or "xen,smccc" in DT.
But is this right?
Answering to this question after some thoughts and discussion around.
The generic approach is indeed the best solution, however I am afraid it
will
On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
> Peter Zijlstra writes:
>
> > On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
> >
> >> > > Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote
> >> > > TLB flush
> >>
> >> > > Hold on.. if we don't
On 11/08/17 11:56, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
>> Peter Zijlstra writes:
>>
>>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>>>
>> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote
>> TLB fl
flight 112579 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112579/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
Hi Andrii,
Thank you very much for your feedback, please see my answers below.
On Thu, Aug 10, 2017 at 1:13 PM, Andrii Anisov
wrote:
> Dear Mirela,
>
> Please see my comments below:
>
>
>
> On 09.08.17 20:43, Mirela Simonovic wrote:
>
>> This document contains our draft proposal for implementin
On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> On 08/08/2017 09:09 AM, Wei Liu wrote:
> > Ian and Stefano
> >
> > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > p9 instead of p9s. This causes problem for his work to rework device
> > framework.
> >
> >
>>> On 27.07.17 at 18:19, wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variab
On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote:
> >> Oh, I see your concern. Hyper-V, however, is not the first x86
> >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
> >> too. Briefly looking at xen_flush_tlb_others() I don't see anything
> >> special, do we kno
flight 112586 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112586/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
On 11/08/17 12:56, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
>> Peter Zijlstra writes:
>>
>>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>>>
>> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote
>> TLB fl
>>> On 27.07.17 at 18:19, wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variab
flight 112577 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
> No cpu can rely on an address being accessible just because IF is being
> cleared. All that matters is the existing and valid page table entry.
>
> So clearing
On Thu 2017-08-10 10:26:05, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
>
> S
* Thomas Garnier wrote:
> Changes:
> - v2:
>- Add support for global stack cookie while compiler default to fs without
> mcmodel=kernel
>- Change patch 7 to correctly jump out of the identity mapping on kexec
> load
> preserve.
>
> These patches make the changes necessary to
On 11/08/17 14:35, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
>> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
>> No cpu can rely on an address being accessible just because IF is being
>> cleared. All that matters is the existing
* Juergen Gross wrote:
> On 08/08/17 16:00, Boris Ostrovsky wrote:
> > On 08/08/2017 02:46 AM, Juergen Gross wrote:
> >> On 28/07/17 12:23, Juergen Gross wrote:
> >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
> >>> HVM guest with KASLR enabled wouldn't boot any longer du
On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> IPI is serving two purposes here: TLB flushing (which is allowed to
> happen at any time) and serialization regarding access to critical pages
> (which seems t
This run is configured for baseline tests only.
flight 71963 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71963/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7
baseline v
On 11/08/17 14:54, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
>> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
>> IPI is serving two purposes here: TLB flushing (which is allowed to
>> happen at any time) and serialization regar
>>> On 27.07.17 at 18:50, wrote:
> On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote:
>> This in turn calls for p2m_alloc_ptp() also being passed the numeric
>> level.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v2: New.
>> ---
>> Question is whether passing the level to p2m_alloc_ptp() is reall
Hi Julien,
On 11.08.17 00:09, Julien Grall wrote:
On 10/08/2017 21:09, Volodymyr Babchuk wrote:
Hi,
On 10.08.17 21:18, Julien Grall wrote:
Hi,
On 10/08/17 18:40, Volodymyr Babchuk wrote:
On 10.08.17 19:11, Julien Grall wrote:
On 10/08/17 16:33, Volodymyr Babchuk wrote:
Hi Julien,
O
Reported-by: Julien Grall
Signed-off-by: Jan Beulich
---
v2: Comment the pl2e related ASSERT().
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5903,7 +5903,7 @@ int modify_xen_mappings(unsigned long s,
{
l3_pgentry_t *pl3e = virt_to_xen_l3e(v);
-if ( !(l3e_get_flags(
1: simplify p2m_next_level()
2: make p2m_alloc_ptp() return an MFN
3: pass level instead of page type to p2m_next_level()
Signed-off-by: Jan Beulich
See individual patches for change info.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
Calculate entry PFN and flags just once. Convert the two successive
main if()-s to and if/else-if chain. Restrict variable scope where
reasonable. Take the opportunity and also make the induction variable
unsigned.
This at once fixes excessive permissions granted in the 2M PTEs
resulting from spli
None of the callers really needs the struct page_info pointer.
Signed-off-by: Jan Beulich
Acked-by: George Dunlap
---
v3: Re-base over changes to patch 1.
v2: Re-base over changes to patch 1.
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -569,7 +569,7 @@ int p2m_set_entry(struct p2
flight 112581 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112581/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
112557
Regressions
This in turn calls for p2m_alloc_ptp() also being passed the numeric
level.
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
---
v2: New.
---
Question is whether passing the level to p2m_alloc_ptp() is really all
that useful: p2m-ept.c's passes zero only anyway, and p2m.c's uniform
passing
On 10.08.17 00:22, Julien Grall wrote:
On 09/08/2017 22:06, Volodymyr Babchuk wrote:
Hi Julien,
On 09.08.17 23:34, Julien Grall wrote:
On 09/08/2017 20:44, Volodymyr Babchuk wrote:
On ARMv8, one of conditional exceptions (SMC that originates
from aarch32 state) have extra field in HCR.I
The hypercall argument translation area lives in the per-domain mappings in
PML4 slot 260. Nothing currently resides in the lower canonical half above
the 4GB boundary in a 32bit PV guest.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/include/asm-x86/config.h | 8 ++--
1 file ch
On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote:
> On 11/08/17 14:54, Peter Zijlstra wrote:
> > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> >> IPI is serving two purposes here: TLB flush
On 11/08/17 14:26, Volodymyr Babchuk wrote:
On 10.08.17 00:22, Julien Grall wrote:
On 09/08/2017 22:06, Volodymyr Babchuk wrote:
Hi Julien,
On 09.08.17 23:34, Julien Grall wrote:
On 09/08/2017 20:44, Volodymyr Babchuk wrote:
On ARMv8, one of conditional exceptions (SMC that originate
flight 112596 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112596/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
Hello All,
Is there any way in linux e.g using device tree, to give a driver a fixed
physical memory range to alloc pages from? All pages are allocated from kernel
memory assigned using memory node in device tree. Is there any way to create a
memory node and assign it to driver so that buddy a
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.
Signed-off-by: Andre Przywar
Since IOREQ servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew C
There is a substantial amount of code duplicated between the x86 and arm
implementations of mm.c:xenmem_add_to_physmap_one() for
XENMAPSPACE_grant_table. Also, the code in question looks like it really
should be in common/grant_table.c
This patch introduces a new function in common/grant_table.c t
This patch changes use of bool_t to bool in the IOREQ server code. It also
fixes an incorrect indentation in a continuation line.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dm.c
Legacy emulators use the 'default' IOREQ server which has slightly
different semantics than other, explicitly created, IOREQ servers.
Because of this, most of the initialization and teardown code needs to
know whether the server is default or not. This is currently achieved
by passing an is_defaul
This series introduces support for direct mapping of guest resources.
The resources are:
- Grant tables
- IOREQ server pages
Paul Durrant (12):
[x86|arm]: remove code duplication
x86/mm: allow a privileged PV domain to map guest mfns
x86/mm: add HYPERVISOR_memory_op to acquire guest resour
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.
This patch adds a new memory op to allow such resourced t
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
This patch re-works much of the IOREQ server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.
This patch removes a check which curr
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
So far a virtual interrupt's priority is stored in the irq_rank
structure, which covers multiple IRQs and has a single lock for this
group.
Generalize the already existing priority variable in struct pending_irq
to not only cover LPIs, but every
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
As the priority value is now officially a member of struct pending_irq,
we need to take its lock when manipulating it via ITS commands.
Make sure we take the IRQ lock after the VCPU lock when we need both.
Signed-off-by: Andre Przywara
---
xe
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
A subsequent patch will introduce a new scheme to allow an emulator to
map IOREQ server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
This patch adjusts the IOREQ server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: Jan Beulich
---
xen/arch/x86/hvm/ioreq.c | 42
xen/include/asm-x86/hvm/domain.h |
On 29/07/17 18:59, Liu Shuo wrote:
> Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt
> during driver irq_disable/irq_enable. Here is the scenario,
> 1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel)
> 2. dev interrupt raised by HW and Xen mark its evtchn as pendi
When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.
Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just u
On Fri, Aug 11, 2017 at 5:36 AM, Pavel Machek wrote:
> On Thu 2017-08-10 10:26:05, Thomas Garnier wrote:
>> Change the assembly code to use only relative references of symbols for the
>> kernel to be PIE compatible.
>>
>> Position Independent Executable (PIE) support will allow to extended the
>>
On Fri, Aug 11, 2017 at 5:41 AM, Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
>> Changes:
>> - v2:
>>- Add support for global stack cookie while compiler default to fs without
>> mcmodel=kernel
>>- Change patch 7 to correctly jump out of the identity mapping on kexec
>> load
>>
To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
set, but this was done only when ACPI tables are built which is not
needed for a Xen guest. The need for the property starts with commit
"pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
(f0c9d64a68b776374ec4732424a3e27753c
This reverts commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492.
This patch prevents PCI passthrough hotplug on Xen. Even if the Xen tool
stack prepares its own ACPI tables, we still rely on QEMU for hotplug
ACPI notifications.
The original issue is fixed by the previous patch (hw/acpi: Call
acpi_se
Adding PCI passthrough before the guest start works fine (broken in 2.9 but now
fixed), but hotplug does not work anymore.
Anthony PERARD (2):
hw/acpi: Call acpi_set_pci_info when no ACPI tables needed
Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen"
hw/acpi/piix4.c | 11 +++--
This commit makes the changes to the hypervisor, the build system as
well as libxc necessary in order to facilitate tracing of program counters.
A discussion of the design can be found in the mailing list:
https://lists.xen.org/archives/html/xen-devel/2017-05/threads.html#02210
The list of files
Make sure the reserved regions are setup before enabling the DMA
remapping in the IOMMU, by calling dom0_setup_permissions before
iommu_hwdom_init. Also, in order to workaround IOMMU issues seen on
pre-Haswell Intel hardware, as described in patch "introduce a PVH
implementation of iommu_inclusive_
Hello,
Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch
series allows using it for a PVH Dom0, which seems to be required in order to
boot on older boxes.
Git branch can be found at:
git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v2
Thanks, Roger.
This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/dom0_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 3
They are emulated by Xen, so they must not be mapped into Dom0 p2m.
Introduce a helper function to add the MMCFG areas to the list of
denied iomem regions for PVH Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since RFC:
- Introduce as helper instead of
On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
trying to boot a PVH Dom0 will freeze the box completely, up to the point that
not even the watchdog works. The freeze happens exactly when enabling the DMA
remapping in the IOMMU, the last line seen is:
(XEN) [VT-D]iommu_
From: Manish Jaggi
add_to_host_its_list will update the host_its_list. This common function to
be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c | 36 +++-
1 file changed, 23 insertions(+), 13 d
From: Manish Jaggi
This patch is split into 5 patches. First two add support for updating
host_its_list from ACPI MADT table.
The rest patches provide support to update the hardware domain MADT table
with ITS information.
Changes since v1:
- split patches into smaller ones
- removed translation_
From: Manish Jaggi
Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 24
xen/arch/arm/gic-v3.c| 1 +
xen/include/asm-arm/gic_v3_its.h | 1 +
3 files changed, 26 insertio
From: Manish Jaggi
Added gicv3_its_acpi_init to update host_its_list from MADT table.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 14 ++
xen/arch/arm/gic-v3.c| 8
xen/include/asm-arm/gic_v3_its.h | 13 +
3 files changed, 35 i
From: Manish Jaggi
estimate_acpi_efi_size needs to be updated to provide correct size of
hardware domains MADT, which now adds ITS information as well.
Introducing gic_get_hwdom_madt_size.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/domain_build.c | 7 +--
xen/arch/arm/gic-v2.c
From: Manish Jaggi
This patch extends the gicv3_iomem_deny_access functionality by adding support
for its region as well. Added function gicv3_its_deny_access.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 19 +++
xen/arch/arm/gic-v3.c| 7 +
On Fri, 11 Aug 2017, Wei Liu wrote:
> On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> > On 08/08/2017 09:09 AM, Wei Liu wrote:
> > > Ian and Stefano
> > >
> > > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > > p9 instead of p9s. This causes problem for hi
On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when ACPI tables are built which is not
> needed for a Xen guest. The need for the property starts with commit
> "pc: pcihp: avoid
flight 112588 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112544
Tests which
On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote:
> Hi,
>
Hey! :-)
> At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote:
> > In Xen, that is impossible, and that's particularly problematic
> > when system is idle (or lightly loaded) systems, as CPUs that
> > are idle may never have th
flight 112594 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112594/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3
baseline version:
ovmf f8daac8121e66c46d3374
Currently, cpregs.h is included in pretty much every files even for
arm64. However, the only use for arm64 is when emulating co-processors.
For arm32, cpregs.h rely on the presence of processor.h (define
*_SYSREG helpers). So move the inclusion in asm-arm/arm32/processor.h.
cpregs.h will also be
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0ab5a..1d835d321d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -9,6 +9,9
sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it
in arm64 sub-directory to reflect that and remove the #ifdef.
At the same time, fixup the guards.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/arm64/processor.h | 2 ++
xen/include/asm-arm/{ => arm64}/sysregs.h
While re-ordering the include alphabetically in arch/arm/domain.c, I got
a complitation error because grant_table.h is using gfn_t before been
defined:
In file included from domain.c:14:0:
xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’
gfn_t
Signed-off-by: Julien Grall
---
xen/arch/arm/vtimer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 32ac1279ae..9c7e8f441c 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -18,16 +18,17 @@
*/
The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move
them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c
No functional change.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/vsysreg.c | 229 ++
The co-processor emulation is quite big and pretty much standalone. Move
it in a separate file to shrink down the size of traps.c.
At the same time remove unused cpregs.h.
No functional change.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/traps.c| 4
A follow-up patch will move some parts of traps.c in separate files.
The will require to use helpers that are currently statically defined.
Export the following helpers:
- inject_undef64_exception
- inject_undef_exception
- check_conditional_instr
- advance_pc
- handle_raz_wi
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b518..ca9bef712c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps
Hi all,
xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate in separate files. This will avoid to grow
traps.c when adding more registers emulations (coming soon).
A branch with this series has been pushed:
https://xenbits.xen.org/git-
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 48c7682671..cbeac28b28 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -19,16 +19,17 @@
*/
It will be necessary to include vtimer.h from subdirectory making the
inclusion a bit awkward.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c | 2 +-
xen/arch/arm/traps.c | 2 +-
xen/{arch/arm => include/asm-arm}/vtimer.h | 0
3 files changed, 2
On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> format. The original code isn't suitable to the new format. A new pair
> bind/unbind interfaces are added for this usage. This patch recogn
1 - 100 of 117 matches
Mail list logo
