Hello,
I have a question and I'm sure it is a question of many users. A beginner
that wants to develop Xen, which skills he/she needed and which file is
good for start? The Xen Project is a big project and have a lot of files
and codes. Where is the best point to start? I see that in the "
xenproje
add_sized() should use an atomic update of the memory word, as it is
used by spin_unlock().
With ticket locks unlocking needs to be atomic in order to avoid very
rare races when someone tries to get the lock while the lock holder
is just releasing it.
Signed-off-by: Juergen Gross
---
xen/includ
> On Aug 5, 2019, at 6:30 PM, Dario Faggioli wrote:
>
> On Mon, 2019-08-05 at 17:04 +0100, George Dunlap wrote:
>> On 8/5/19 4:58 PM, Jan Beulich wrote:
>>> On 26.07.2019 08:25, Dario Faggioli wrote:
>>> 1) The commit is empty, presumably because I did apply the patch a
>>> few
>>> days a
On 05.08.2019 15:44, Marek Marczykowski-Górecki wrote:
> On Fri, Jul 19, 2019 at 09:43:26AM +, Jan Beulich wrote:
>> On 19.07.2019 11:02, Roger Pau Monné wrote:
>>> On Fri, Jul 19, 2019 at 08:04:45AM +, Jan Beulich wrote:
On 18.07.2019 18:52, Roger Pau Monné wrote:
> On Thu, Jul
On 05.08.2019 18:44, Andrew Cooper wrote:
> Since c/s 9fa94e10585 "x86/ACPI: also parse AMD IOMMU tables early", this
> function is unconditionally called in all cases where a DMAR ACPI table
> doesn't exist.
>
> As a consequnce, "AMD-Vi: IOMMU not found!" is printed in all cases where an
> IOMMU
On 06.08.2019 09:00, Juergen Gross wrote:
> add_sized() should use an atomic update of the memory word, as it is
> used by spin_unlock().
>
> With ticket locks unlocking needs to be atomic in order to avoid very
> rare races when someone tries to get the lock while the lock holder
> is just releas
On 06.08.19 10:26, Jan Beulich wrote:
On 06.08.2019 09:00, Juergen Gross wrote:
add_sized() should use an atomic update of the memory word, as it is
used by spin_unlock().
With ticket locks unlocking needs to be atomic in order to avoid very
rare races when someone tries to get the lock while t
flight 139736 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139736/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 139449
test-amd64-amd64-libvirt-xsm 13
On Tue, Aug 06, 2019 at 07:56:39AM +, Jan Beulich wrote:
> On 05.08.2019 15:44, Marek Marczykowski-Górecki wrote:
> > On Fri, Jul 19, 2019 at 09:43:26AM +, Jan Beulich wrote:
> >> On 19.07.2019 11:02, Roger Pau Monné wrote:
> >>> On Fri, Jul 19, 2019 at 08:04:45AM +, Jan Beulich wrote
flight 139735 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On Mon, Aug 05, 2019 at 11:44:11AM +0200, Dario Faggioli wrote:
> Anyway, it seems that, in addition to the one I mentioned to Anthony a
> few days ago, we also miss this from upstream?
>
> commit 2d2023c3b99edb33ad4bb9791f70456ea1a1c049
> sockets: avoid string truncation warnings when copying UNI
On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 07:56:39AM +, Jan Beulich wrote:
On 05.08.2019 15:44, Marek Marczykowski-Górecki wrote:
On Fri, Jul 19, 2019 at 09:43:26AM +, Jan Beulich wrote:
On 19.07.2019 11:02, Roger Pau Monné wrote:
On Fri, Jul 19
On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
> On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 06, 2019 at 07:56:39AM +, Jan Beulich wrote:
> > > On 05.08.2019 15:44, Marek Marczykowski-Górecki wrote:
> > > > On Fri, Jul 19, 2019 at 09:43:26AM +, Jan
On Mon, Aug 05, 2019 at 03:49:10PM +0100, Andrew Cooper wrote:
> c/s 986aea7fbe "xl.cfg: add 'cmdline' in config file" introduced cmdline= and
> make extra= and root= unusable if cmdline= was present.
>
> For the vm.cfg file itself, this makes sense. However, for development
> purposes it is very
On 8/5/19 10:42 AM, Jan Beulich wrote:
> On 02.08.2019 18:16, George Dunlap wrote:
>> Commits ec83f825627 "mm.h: add helper function to test-and-clear
>> _PGC_allocated" (and subsequent fix-up 44a887d021d "mm.h: fix BUG_ON()
>> condition in put_page_alloc_ref()") introduced a BUG_ON() to detect
>>
Anthony PERARD writes ("Re: [PATCH] tools/xl: Make extra= usable in combination
with cmdline="):
> On Mon, Aug 05, 2019 at 03:49:10PM +0100, Andrew Cooper wrote:
> > # xl create shim.cfg ramdisk=\"test-hvm64-example\" extra=\"dom0=pvh\
> > dom0-iommu=none\"
> >
> > without needing to edit shim.
flight 139737 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139678
test-arm64-arm64-
On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 07:56:39AM +, Jan Beulich wrote:
On 05.08.2019 15:44, Marek Marczykowski-Górecki wrote:
I'm
On Tue, Aug 06, 2019 at 02:05:48PM +0200, Jan Beulich wrote:
> On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
> > > On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
> > > > On Tue, Aug 06, 2019 at 07:56:39AM +, Jan
Only the first patch here is left from v4, everything else is new,
yet still related. The main goal is to reduce the huge memory
overhead that we've noticed. On the way there a number of other
things were once again noticed. Unfortunately before I was able to
also test the last two patches there,
The blank line between it and the prior if() clearly indicates that this
was meant to be a standalone if().
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -166,8 +166,8 @@ static int __init iov_detec
First and foremost switch boolean fields to bool. Adjust a few related
function parameters as well. Then
- in amd_iommu_set_intremap_table() don't use literal numbers,
- in iommu_dte_add_device_entry() use a compound literal instead of many
assignments,
- in amd_iommu_setup_domain_device()
- e
Calling amd_iommu_free_intremap_table() for every IVRS entry is correct
only in per-device-IRT mode. Use a NULL 2nd argument to indicate that
the shared table should be freed, and call the function exactly once in
shared mode.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthroug
Additional users of the function will want to handle errors more
gracefully. Remove the BUG_ON()s and make the current caller panic()
instead.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -86,6 +86,10 @@
For us to no longer blindly allocate interrupt remapping tables for
everything the ACPI tables name, we can't use struct ivrs_mappings'
intremap_table field anymore to also have the meaning of "this entry
is valid". Add a separate boolean field instead.
Signed-off-by: Jan Beulich
---
v5: New.
-
Rather than duplicating entries in amd_iommu_msi_msg_update_ire(), share
the tables. This mainly requires some care while freeing them, to avoid
freeing memory blocks twice.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/
ACPI tables are free to list far more device coordinates than there are
actual devices. By delaying the table allocations for most cases, and
doing them only when an actual device is known to be present at a given
position, overall memory used for the tables goes down from over 500k
pages to just
Hello Dario,
Please see my comments below:
On 03.08.19 03:55, Dario Faggioli wrote:
On Fri, 2019-08-02 at 16:07 +0300, Andrii Anisov wrote:
On 02.08.19 12:15, Julien Grall wrote:
From the list below it is not clear what is the split between
hypervisor time and guest time. See some of the ex
Rather than doing this every time we set up interrupts for a device
anew (and then in two distinct places) fill this invariant field
right after allocating struct arch_msix.
While at it also obtain the MSI-X capability structure position just
once, in msix_capability_init(), rather than in each c
Prepare for the number of entries to not be the maximum possible, by
separating checks against maximum size from ones against actual size.
For caller side simplicity have alloc_intremap_entry() return the
maximum possible value upon allocation failure, rather than the first
just out-of-bounds one.
There's no point setting up tables with more space than a PCI device can
use. For both MSI and MSI-X we can determine how many interrupts could
be set up at most. Tables allocated during ACPI table parsing, however,
will (for now at least) continue to be set up to have maximum size.
Note that unt
Current code calls apic_x2apic_probe which does some initialization
and setup before having enabled x2APIC mode (if it's not already
enabled by the firmware).
This can lead to issues if the APIC ID doesn't match the x2APIC ID, as
apic_x2apic_probe calls init_apic_ldr_x2apic_cluster which depending
On Tue, 2019-08-06 at 11:12 +0100, Anthony PERARD wrote:
> On Mon, Aug 05, 2019 at 11:44:11AM +0200, Dario Faggioli wrote:
> > Anyway, it seems that, in addition to the one I mentioned to
> > Anthony a
> > few days ago, we also miss this from upstream?
> >
> > commit 2d2023c3b99edb33ad4bb9791f7045
On 06.08.2019 14:43, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 02:05:48PM +0200, Jan Beulich wrote:
On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
On
On Tue, Aug 06, 2019 at 03:17:26PM +0200, Dario Faggioli wrote:
> On Tue, 2019-08-06 at 11:12 +0100, Anthony PERARD wrote:
> > with those two I could build a qemu in the tumbleweed container, but
> > there are maybe other commit missing.
> >
> You mean the build is still failing for you, but not i
On 8/5/19 11:57 AM, Ian Jackson wrote:
> Hi. Thanks for looking into this. Sorry about the delay to the
> review. I found it, unsent, while recovering a crashed mailreader
> session...
Thanks for the review -- I was going to come back and ping this at some
point; it would be nice to have it in
On Tue, Aug 06, 2019 at 02:43:49PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 06, 2019 at 02:05:48PM +0200, Jan Beulich wrote:
> > On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
> > > On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
> > > > On 06.08.2019 11:46, Mare
flight 139765 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139765/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 06.08.2019 15:13, Roger Pau Monne wrote:
Current code calls apic_x2apic_probe which does some initialization
and setup before having enabled x2APIC mode (if it's not already
enabled by the firmware).
This can lead to issues if the APIC ID doesn't match the x2APIC ID, as
apic_x2apic_probe call
Hi Viktor,
Viktor Mitin writes:
> Extend fdt_property_interrupts to deal with other domain than the hwdom.
>
> The prototype of fdt_property_interrupts() has been modified
> to support both hwdom and domU in one function.
>
> This is a preparatory for the next patch which consolidates
> make_tim
Hi Viktor,
Viktor Mitin writes:
> Functions make_timer_node and make_timer_domU_node are quite similar.
> So it is better to consolidate them to avoid discrepancy.
> The main difference between the functions is the timer interrupts used.
>
> Keep the domU version for the compatible as it is simp
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in two distinct places) fill this invariant field
> right after allocating struct arch_msix.
>
> While at it also obtain the MSI-X capability structur
On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
> There is nothing interesting for assembly code in msr.h
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
If those are the only assembly files including msr.h, could you also
get rid of the assembly guard in msr.h?
T
On 06.08.2019 16:25, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
@@ -1093,22 +1094,17 @@ static void __pci_disable_msi(struct msi
**/
static int __pci_enable_msix(struct msi_info *msi, struct msi_desc **desc)
{
-int pos, nr_entries;
struc
On 06.08.2019 16:39, Roger Pau Monné wrote:
On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
There is nothing interesting for assembly code in msr.h
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
___
On Mon, Aug 05, 2019 at 01:43:00PM +0100, Andrew Cooper wrote:
> The current names, boot_cpu_{,compat_}gdt_table, have a table suffix which is
> redundant with the T of GDT, and the cpu infix doesn't provide any meaningful
> context. Drop them both.
>
> Likewise, shorten the {,compat_}gdt{,_l1e}
On Mon, Aug 05, 2019 at 01:43:01PM +0100, Andrew Cooper wrote:
> ... where we can at least get the compiler to fill in the surrounding space
> without having to do it manually. This also reults in the symbols having
> proper type/size information in the debug symbols.
>
> Reorder 'raw' in the seg
On 06/08/2019 15:39, Roger Pau Monné wrote:
> On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
>> There is nothing interesting for assembly code in msr.h
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
>
> If those are the only assembly files including msr.h, could
On Tue, Aug 06, 2019 at 04:47:28PM +0200, Jan Beulich wrote:
> On 06.08.2019 16:25, Roger Pau Monné wrote:
> > On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
> > > --- a/xen/drivers/passthrough/pci.c
> > > +++ b/xen/drivers/passthrough/pci.c
> > > @@ -324,6 +324,7 @@ static void appl
On 05.08.2019 14:42, Andrew Cooper wrote:
Split up the long asm block by commenting the logical subsections.
The movabs for obtaining __start_xen can be a rip-relative lea instead. This
has the added advantage that objdump can now cross reference it during
disassembly.
I'm surprised this work
On 06.08.2019 17:16, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 04:47:28PM +0200, Jan Beulich wrote:
On 06.08.2019 16:25, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
@@ -350,6 +353,10 @@ static struct pci_dev *ºalloc_pdev(struct
retu
On 06.08.2019 16:51, Roger Pau Monné wrote:
On Mon, Aug 05, 2019 at 01:43:00PM +0100, Andrew Cooper wrote:
The current names, boot_cpu_{,compat_}gdt_table, have a table suffix which is
redundant with the T of GDT, and the cpu infix doesn't provide any meaningful
context. Drop them both.
Likew
On 8/5/19 4:38 AM, Julien Grall wrote:
> CAUTION: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> Hi,
>
> I have CCed one person from Donerworks. IIRC they have been using the IMX
On 05.08.2019 14:43, Andrew Cooper wrote:
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -43,44 +43,11 @@ ENTRY(__high_start)
multiboot_ptr:
.long 0
-.word 0
-GLOBAL(boot_gdtr)
-.word LAST_RESERVED_GDT_BYTE
-.quad boot_gdt - FI
On 30.07.2019 15:44, Paul Durrant wrote:
This function is only ever called from within the same source module and
really has no business being declared xen/iommu.h. This patch relocates
the function ahead of the first called and makes it static.
Signed-off-by: Paul Durrant
Acked-by: Jan Beuli
On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > This patch completely fixes the problem for me!
> >
> > Thanks Roger! I'd love to see this in Xen 4.13
>
> Thanks for testing!
>
> It's still not clear to me w
flight 139770 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139770/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello,
With the embargo up, you'll surely all be pleased to see that this is
not a zeroday XSA.
https://www.bitdefender.com/SWAPGSAttack
There are two issues here.
1) Spectre attacks against SWAPGS in interrupt/exception handlers
This has been assigned CVE-2019-1125 and affects all 64bit oper
Add 9pfs to the kind of PV drivers that has a QEMU backend, specifically
to the macro QEMU_BACKEND.
This is needed otherwise upon domain destroy we get a timeout error:
libxl: error: libxl_device.c:1132:device_backend_callback: Domain 1:unable to
remove device with path /local/domain/0/backend/9
On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Provide a more capable variation of put_user_pages_dirty_lock(),
> and delete put_user_pages_dirty(). This is based on the
> following:
>
> 1. Lots of call sites become simpler if a bool is passed
>
flight 139740 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 139714
test-amd64-amd64-x
flight 139751 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139751/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 76e40d7be239893dbf9844515392779c3ab2fba0
baseline version:
ovmf aefcf2f78a4800ab64697
On Mon, Aug 05, 2019 at 05:44:30PM +0100, Andy Cooper wrote:
> Since c/s 9fa94e10585 "x86/ACPI: also parse AMD IOMMU tables early", this
> function is unconditionally called in all cases where a DMAR ACPI table
> doesn't exist.
>
> As a consequnce, "AMD-Vi: IOMMU not found!" is printed in all case
flight 139743 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139743/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrat
On 05.08.19 13:02, Jan Beulich wrote:
Hi, Jan
While I can see why having a re-allocation function may be handy,
explicit / direct use of _xmalloc() and _xzalloc() are discouraged,
in favor of the more type-safe underscore-less variants.
took into account
I can't
see though how a type-safe
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 7/8/19 8:02 PM, Oleksandr wrote:
> > On 22.06.19 02:56, Stefano Stabellini wrote:
> > I have tested this series and got the same behavior as with V2 [1].
> >
> > The "non-reserved-memory" node in my device-tree
> > (sram@47FFF000->scp_shmem@0)
On Tue, 9 Jul 2019, Oleksandr wrote:
>
> On 22.06.19 02:56, Stefano Stabellini wrote:
>
> Hi, Stefano
>
> > Don't allow reserved-memory regions to be remapped into any guests,
> > until reserved-memory regions are properly supported in Xen. For now,
> > do not call iomem_permit_access for them.
On Thu, Jul 25, 2019 at 01:33:50PM +, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal inste
Hi Jan,
Jan Beulich writes:
> On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
>> --- a/xen/common/xmalloc_tlsf.c
>> +++ b/xen/common/xmalloc_tlsf.c
>> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
>> return p ? memset(p, 0, size) : p;
>> }
>>
>> +void *
On Tue, Aug 06, 2019 at 03:07:48PM +0200, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal inste
On 8/6/19 10:39 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
...
>> -
>> /**
>> - * put_user_pages_dirty() - release and dirty an array of gup-pinned pages
>> - * @pages: array of pages to be marked dirty and released.
>> +
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 6/22/19 12:56 AM, Stefano Stabellini wrote:
> > As we parse the device tree in Xen, keep track of the reserved-memory
> > regions as they need special treatment (follow-up patches will make use
> > of the stored information.)
> >
> > Reuse pro
Hi Nate , Hi Julien,
>
> Amit,
>
> Have you checked out the NXP Xen fork?
>
> https://source.codeaurora.org/external/imx/imx-xen/
>
> While the work there hasn't been upstreamed yet, the support for the
> iMX8QM
> (QuadMax) is fairly complete. There are some important dif
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win10-i386
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Hi
>
> What are the consequences to change the interrupt parent?
I am not entirely sure about it at the moment but looks like it
controllers power domain
for various devices like GPU, VPU and OTG etc.
So, we may not be able to support these devices for XEN domains ?
Also, this IP is not present
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/22/19 12:56 AM, Stefano Stabellini wrote:
> > Reserved memory regions are automatically remapped to dom0. Their device
> > tree nodes are also added to dom0 device tree. However, the dom0 memory
> > node is not currently extended to c
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if there is no reg property, remove printk.
Return error
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
>
> On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > > This patch completely fixes the problem for me!
> > >
> > > Thanks Roger! I'd love to see this in X
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_permit_access for them.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- compare the parent name with reserved-memory
- use dt_node_cm
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Change make_memory_node to tak
Add new parameters to device_tree_for_each_node: node, depth,
address_cells, size_cells.
Node is the parent node to start the search from;
depth is the min depth of the search (the depth of the parent node);
address_cells and size_cells are the respective parameters at the parent
node. Passing 0, 0
Hi all,
This patch series introduces partial reserved-memory support for dom0
only (no domU support for reserved-memory yet.)
The following changes since commit 45ce5b8749a220ad7c4ce5d5eba7c201a9418078:
mm: Safe to clear PGC_allocated on xenheap pages without an extra reference
(2019-08-06 1
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.
Refuse to continue once we reach t
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- new patch
---
xen/arch/arm/bootfdt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
dif
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled accordingly:
consider_modules and dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserve regions.
Signed-off-by: Stefano Stabellini
Acked-
flight 139756 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139688
Tests which did not
On Wed, 19 Jun 2019, Jan Beulich wrote:
> >>> On 19.06.19 at 01:20, wrote:
> > Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
> > ARM and p2m_mmio_direct on x86 -- no changes in behavior. On x86,
> > introduce a macro to strip away the last parameter and rename the
> > exist
Commit 4941bfbf11eae05c92aa3242e353d173974ce7bf "xen/arm64: macros:
Introduce an assembly macro to alias x30" moved
lr .reqx30
to macros.h, and started to use "lr" in head.S. However, it didn't add
an #include macros.h to head.S. This commit fixes it.
Signed-off-by: Stefano Stabellini
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> The Arm code looks good to me. One comment below.
Should I take it as a acked-by?
> On 6/19/19 12:20 AM, Stefano Stabellini wrote:
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index e28ea1c85a..d88df11e09 100644
> > ---
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 6/19/19 12:20 AM, Stefano Stabellini wrote:
> > Reuse the existing padding field to pass memory policy information. On
> > Arm, the caller can specify whether the memory should be mapped as
> > Device-nGnRE (Device Memory on Armv7) at stage-2,
On Wed, 19 Jun 2019, Jan Beulich wrote:
> >>> On 19.06.19 at 01:20, wrote:
> > --- a/tools/libxc/xc_domain.c
> > +++ b/tools/libxc/xc_domain.c
> > @@ -2070,6 +2070,7 @@ int xc_domain_memory_mapping(
> > domctl.cmd = XEN_DOMCTL_memory_mapping;
> > domctl.domain = domid;
> > domctl.u.
flight 139753 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-amd64-i386-qemu
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_dev_nGnRE, Device-nGnRE, the default on Arm
- arm_mem_WB, WB cachable memory
- default
Store the parameter in a new field in libxl_iomem_range.
Pass the memory policy option to xc_domain_mem_map_policy.
Do the lib
Reuse the existing padding field to pass memory policy information. On
Arm, the caller can specify whether the memory should be mapped as
Device-nGnRE (Device Memory on Armv7) at stage-2, which is the default
and the only possibility today, or cacheable memory write-back. The
resulting memory attri
iomem settings fall under the broader category of "Non-PCI device
passthrough": they are not security supported. Make it clearer.
Signed-off-by: Stefano Stabellini
CC: t...@xen.org
CC: konrad.w...@oracle.com
CC: Julien Grall
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: ian.jack...@eu.
Add a p2m_is_mmio macro for easy checkings.
Signed-off-by: Stefano Stabellini
---
xen/include/asm-arm/p2m.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 03f2ee75c1..31902317da 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xe
Hi all,
This series introduces a memory policy parameter for the iomem option,
so that we can map an iomem region into a guest as cacheable memory.
(Other things related to reserved-memory on Arm have been sent
separately.)
Cheers,
Stefano
The following changes since commit 45ce5b8749a220ad7c
Introduce a new libxc function that makes use of the new memory_policy
parameter added to the XEN_DOMCTL_memory_mapping hypercall.
The parameter values are the same for the XEN_DOMCTL_memory_mapping
hypercall (0 is MEMORY_POLICY_DEFAULT). Pass MEMORY_POLICY_DEFAULT by
default -- no changes in beha
Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
ARM and p2m_mmio_direct on x86 -- no changes in behavior.
On x86, introduce a macro to strip away the last parameter and rename
the existing implementation of map_mmio_regions to map_mmio_region.
Use map_mmio_region in vpci as i
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder v
1 - 100 of 147 matches
Mail list logo
