flight 138986 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138986/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 7 xen-boot fail in 138948 pass in 138986
test-amd64-i386-xl-qemuu-debianh
On 15.07.2019 07:05, Zhenzhong Duan wrote:
>
> On 2019/7/12 22:06, Andrew Cooper wrote:
>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
>>> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
>>> selftest") is used to ensure there is a gap setup in exception stack
>>> which could be used
flight 138998 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138998/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70565e64227dfa254d8a0703dd60dc74bd8b5e6e
baseline version:
ovmf 55b9bbf40a1cf9788dd6a
> -Original Message-
> From: Jan Beulich
> Sent: 10 July 2019 23:53
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ;
On 01.07.2019 13:59, Jan Beulich wrote:
> A majority of callers wants just a single iteration handled. Allow to
> express this by passing in a NULL pointer, instead of setting up a local
> variable just to hold the "1" to pass in here.
>
> Signed-off-by: Jan Beulich
> ---
> Note that this conflic
On 05.07.2019 18:06, Jan Beulich wrote:
On 05.06.19 at 08:51, wrote:
>> First and foremost make timer_softirq_action() avoid growing the heap
>> if its new size can't be stored without truncation. 64k entries is a
>> lot, and I don't think we're at risk of actually running into the issue,
>>
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 13:00
> To: xen-devel@lists.xenproject.org; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monne
> ; Paul Durrant
> Subject: [PATCH] x86/hvm: make hvmemul_virtual_to_linear()'s reps parameter
> opt
On 12.07.2019 04:28, Jan Beulich wrote:
> On 11.07.2019 19:13, Tamas K Lengyel wrote:
>>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>>
>>>ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
>>>}
>>> +
>>> +if ( curr->arch.vm_event &&
>
On 03.07.2019 13:29, Jan Beulich wrote:
On 27.05.19 at 11:36, wrote:
> On 12.04.19 at 13:41, wrote:
>> On 11.04.19 at 21:06, wrote:
On 11/04/2019 13:45, Jan Beulich wrote:
> When disabling SMT at runtime, secondary threads should no longer be
> candidates for bringing b
On 03.07.2019 13:36, Jan Beulich wrote:
> The write-discard property of the type can't be represented in IOMMU
> page table entries. Make sure the respective checks / tracking can't
> race, by utilizing the domain lock. The other sides of the sharing/
> paging/log-dirty exclusion checks should subs
>>> On 27.05.19 at 11:25, wrote:
On 13.03.19 at 13:39, wrote:
> > While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> > expensive (but still needed only for the toggle_guest_mode() path), the
> > effect of the latter on the exit-to-guest path is not insignificant.
> >
On 15/07/2019 07:54, Jan Beulich wrote:
> On 15.07.2019 07:05, Zhenzhong Duan wrote:
>> On 2019/7/12 22:06, Andrew Cooper wrote:
>>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:
[0.772876] gener
The _PGC_allocated flag is set on a page when it is assigned to a domain
along with an initial reference count of at least 1. To clear this
'allocation' reference it is necessary to test-and-clear _PGC_allocated and
then only drop the reference if the test-and-clear succeeds. This is open-
coded in
On 15.07.2019 10:45, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 10 July 2019 23:53
>>
>> On 10.07.2019 18:17, Paul Durrant wrote:
>>> @@ -418,13 +417,7 @@ static void hvm_free_ioreq_mfn(struct hvm_ioreq_server
>>> *s, bool buf)
>>>unmap_domain_page_global(iorp->va);
>>>iorp
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 10:18
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Volodymyr Babchuk ;
> Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk
> ; T
On 15.07.2019 11:17, Paul Durrant wrote:
> The _PGC_allocated flag is set on a page when it is assigned to a domain
> along with an initial reference count of at least 1. To clear this
> 'allocation' reference it is necessary to test-and-clear _PGC_allocated and
> then only drop the reference if th
On Fri, Jul 12, 2019 at 10:41 PM Ian Jackson wrote:
>
> Here are the photos I took of the flipchart:
> https://xenbits.xen.org/people/iwj/2019/summit-ci-branch-workshop/
FYI, I can see the directory, but when I click on the individual
images, I get this:
You don't have permission to access
/pe
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 10:24
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> VolodymyrBabchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; T
On Fri, Jul 05, 2019 at 04:06:06PM +, Jan Beulich wrote:
> >>> On 05.06.19 at 08:51, wrote:
> > First and foremost make timer_softirq_action() avoid growing the heap
> > if its new size can't be stored without truncation. 64k entries is a
> > lot, and I don't think we're at risk of actually ru
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error: use of logical '&&' with constant operand
[-Werror,-Wconstant-logical-operand]
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^ ~~
dom0_build.c:344:24: note: use '&' for a bitwise
On Mon, Jul 08, 2019 at 11:47:11AM -0700, Chaitanya Kulkarni wrote:
> This patch updates the vbd_sz() macro with newly introduced helper
> function to read the nr_sects from block device's hd_parts with the
> help of part_nr_sects_read().
>
> Signed-off-by: Chaitanya Kulkarni
Acked-by: Roger Pau
On 15.07.2019 11:50, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2019 10:24
>>
>> On 15.07.2019 11:17, Paul Durrant wrote:
>>> The _PGC_allocated flag is set on a page when it is assigned to a domain
>>> along with an initial reference count of at least 1. To clear this
>>> 'allocati
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 11:44
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; VolodymyrBabchuk ;
> Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk
> ; Ta
flight 138992 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138992/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-build fail in 138772 REGR. vs. 132889
build-amd64-pre
Hi,
On 12/07/2019 19:32, Hunyue Yau z wrote:
On Friday, July 12, 2019 16:13:32 Julien Grall wrote:
Hi,
On 7/11/19 7:29 PM, Hunyue Yau wrote:
[This mail incorporates comments raised on IRC. I have made some of this
mHi,ore verbose to provide context to people that haven't seen the IRC
comments
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support and with
Grub2 now supporting PVH officially since version 2.04 there is no
need to keep 32-bit PV
Xen is requiring 64-bit machines today. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can be either HVM or PVH, or they can use a 64 bit kernel.
Remove the 32-bit Xen PV support from the kernel.
Signed-off-by: Juergen Gross
---
arch/x86/
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +
arch/x86/include/asm/paravirt.h | 105
arch/x86/include/asm/paravirt_type
On Thu, Jul 04, 2019 at 03:42:04PM +0100, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
>
On 15/07/2019 12:46, Roger Pau Monné wrote:
>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> new file mode 100644
>> index 00..2a17fed52f
>> --- /dev/null
>> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> @@ -0,0 +1,49 @@
>>
On 7/10/19 3:51 AM, Jan Beulich wrote:
> On 09.07.2019 22:13, George Dunlap wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -343,6 +343,11 @@ M: Marek Marczykowski-Górecki
>>
>> S: Supported
>> F: tools/python
>>
>> +GOLANG BINDINGS
>> +M: George Dunlap
>> +S: Maintain
Signed-off-by: George Dunlap
---
v2:
- Put in alphabetical order
- Replace spaces with tabs
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Konrad Wilk
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
dif
On 15/07/2019 13:01, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15.07.2019 13:09, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2019 11:44
>>
>> Well, the problem is that I don't feel well adjusting what a native
>> English speaking person has written.
>
> Ok. How about...
>
> "This patch adds a helper function, put_page_alloc_ref(), to replac
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
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.gi
On Mon, Jul 15, 2019 at 01:37:37PM +0200, Juergen Gross wrote:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporti
This series is a mixture of tidying and some preparatory work for grouping
PCI devices for the purposes of assignment.
Paul Durrant (4):
iommu / x86: move call to scan_pci_devices() out of vendor code
pci: add all-device iterator function...
iommu: introduce iommu_groups
iommu / pci: re-im
On 15.07.19 14:32, Peter Zijlstra wrote:
On Mon, Jul 15, 2019 at 01:37:37PM +0200, Juergen Gross wrote:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit
It's not vendor specific so it doesn't really belong there.
Scanning the PCI topology also really doesn't have much to do with IOMMU
initialization. It doesn't depend on there even being an IOMMU. This patch
moves to the call to the beginning of iommu_hardware_setup() but only
places it there beca
... using the new iommu_group infrastructure.
Because 'sibling' devices are now members of the same iommu_group,
implement the domctl by looking up the iommu_group of the pdev with the
matching SBDF and then finding all the assigned pdevs that are in the
group.
Signed-off-by: Paul Durrant
---
Cc
...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
The unlock/process-pending-softirqs/lock sequence that was in
_setup_hwdom_pci_devices() is now done in the generic iterator function,
which does mean it is also done (unnecessarily) in the case of
dump_pci_devices(), since run_al
Some devices may share a single PCIe initiator id, e.g. if they are actually
legacy PCI devices behind a bridge, and hence DMA from such devices will
be subject to the same address translation in the IOMMU. Hence these devices
should be treated as a unit for the purposes of assignment. There are al
Below are the raw notes. General agreements seem to be:
* Removing external builds from xen build system is an advantage for the
main users (developers, distros / packagers)
* Out-of-tree build is useful for lots of circumstances; symlink trick
used to work around its lack causes lots of problems
On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
>
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
> ^ ~~~
On 15/07/2019 11:35, Jan Beulich wrote:
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
> ^ ~
Looking through the notes, it seems like the first part of this
discussion, re hypervisor upgrade / downgrade & libraries, was partly
covered in the distro session, in which Debian's Xen version co-install
was discussed and found useful even if we had a hypervisor , Ian Jackson
agreed to post Debia
On 05/07/2019 14:56, Dario Faggioli wrote:
> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
>> 1) This crash is quite likely to happen:
>>
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
>> that CPU2 is stuck!
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.226293] [
Much of this covered things discussed elsewhere:
* Allowing multiple versions of the tools to be installed at the same time
* Getting rid of external builds
There was a long discussion about security patches, with the general
proposal being that we should cut a point release for every security iss
On 15.07.2019 15:41, Tamas K Lengyel wrote:
> On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
>>
>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>
>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>> [-Werror,-Wconstant-logical-operand]
>> if ( !dom0_mem_set &&
On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> works without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions for PVH, han
On 15.07.2019 15:49, Andrew Cooper wrote:
> On 15/07/2019 11:35, Jan Beulich wrote:
>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>
>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>> [-Werror,-Wconstant-logical-operand]
>> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0
On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
> ACPI Timer does not work in a PVH guest, but local APIC works on both
This is not accurate. It's not that the ACPI timer doesn't work, it's
just that it's not present. The PM_TMR_BLK should be set to 0 to
indicate the lack of PM tim
On 15.07.2019 16:11, George Dunlap wrote:
> There was a long discussion about security patches, with the general
> proposal being that we should cut a point release for every security issue.
Interesting. Looks like in politics that until a decision fits people
they keep re-raising the point. Iirc
On Mon, Jul 15, 2019 at 12:50:29PM +0100, Andrew Cooper wrote:
> On 15/07/2019 12:46, Roger Pau Monné wrote:
> >> +;
> >> +; Jump to the main routine of the pre-SEC code
> >> +; skiping the 16-bit part of the routine and
> >> +; into the 32-bit flat mode part
> >> +;
> >> +O
On Mon, Jul 15, 2019 at 01:37:07PM +0100, Paul Durrant wrote:
> It's not vendor specific so it doesn't really belong there.
>
> Scanning the PCI topology also really doesn't have much to do with IOMMU
> initialization. It doesn't depend on there even being an IOMMU. This patch
> moves to the call
This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Therefore convert
generic_hweight() to out-of-line functions (without affecting Arm)
and use alternatives patching to replace the function calls.
Note that the approach doesn#t work fo
flight 138996 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
build-i386-pre
On 7/15/19 3:23 PM, Jan Beulich wrote:
> On 15.07.2019 16:11, George Dunlap wrote:
>> There was a long discussion about security patches, with the general
>> proposal being that we should cut a point release for every security issue.
>
> Interesting. Looks like in politics that until a decision fi
On Mon, Jul 15, 2019 at 8:13 AM Jan Beulich wrote:
>
> On 15.07.2019 15:41, Tamas K Lengyel wrote:
> > On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
> >>
> >> With non-empty CONFIG_DOM0_MEM clang5 produces
> >>
> >> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> >>
On 7/15/19 3:42 PM, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>> Interesting.
On 15.07.2019 16:44, Tamas K Lengyel wrote:
> On Mon, Jul 15, 2019 at 8:13 AM Jan Beulich wrote:
>>
>> On 15.07.2019 15:41, Tamas K Lengyel wrote:
>>> On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error:
On 15.07.2019 16:42, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>> Interesting.
1: guard top-of-stack reads
2: widen condition for logging top-of-stack
The issue patch 2 fixes (a curious lack of an intermediate call stack
entry) was observed in practice; patch 1 is a result of me just looking
at the code.
Jan
___
Xen-devel mailing
On 15/07/2019 15:19, Jan Beulich wrote:
> On 15.07.2019 15:49, Andrew Cooper wrote:
>> On 15/07/2019 11:35, Jan Beulich wrote:
>>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>>
>>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>>> [-Werror,-Wconstant-logical-operand]
>
Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
often for relatively simple leaf functions. (To give a specific example,
the case I've run into this with is _pci_hide_device() and gcc 8.
Interestingly the even more simple neighboring iommu_has_feature() does
get a frame poi
Nothing guarantees that the original frame's stack pointer points at
readable memory. Avoid a (likely nested) crash by attaching exception
recovery to the read (making it a single read at the same time). Don't
even invoke _show_trace() in case of a non-readable top slot.
Signed-off-by: Jan Beulich
On Tue, Jan 10, 2017 at 4:14 PM Juergen Gross wrote:
>
> Today xenstored tries to open a tdb data base file on disk when it is
> started. As this is problematic in most cases the scripts used to start
> xenstored ensure xenstored won't find such a file in order to start
> with an empty xenstore.
On 7/11/19 8:02 AM, Zhenzhong Duan wrote:
> PVH guest needs PV extentions to work, so "nopv" parameter should be
> ignored for PVH but not for HVM guest.
>
> If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
> we know it's PVH guest and ignore "nopv" parameter directly.
>
> If
On Mon, Jul 15, 2019 at 01:37:08PM +0100, Paul Durrant wrote:
> ...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
>
> The unlock/process-pending-softirqs/lock sequence that was in
> _setup_hwdom_pci_devices() is now done in the generic iterator function,
> which does mean it is a
On Mon, Jul 15, 2019 at 01:37:09PM +0100, Paul Durrant wrote:
> Some devices may share a single PCIe initiator id, e.g. if they are actually
> legacy PCI devices behind a bridge, and hence DMA from such devices will
> be subject to the same address translation in the IOMMU. Hence these devices
> sh
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 16:35
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 084de77a109e..d42737f31304 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
> +OBJECT_FILES_NON_STANDAR
On Mon, Jul 15, 2019 at 01:37:10PM +0100, Paul Durrant wrote:
> ... using the new iommu_group infrastructure.
>
> Because 'sibling' devices are now members of the same iommu_group,
> implement the domctl by looking up the iommu_group of the pdev with the
> matching SBDF and then finding all the as
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> vcpu_deassign() has only one caller: _vcpu_remove().
> Let's consolidate the two functions into one.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
___
Xen-dev
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 16:46
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 4/4] iommu / pci: re-implement
> XEN_DOMCTL_get_device_group...
>
> On Mon, Jul 15, 2019 at 01:37:10PM +0100
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> If a pCPU has been/is being offlined, we don't want it to be neither
> assigned to any pCPU, nor in the wait list.
I take it the first `pCPU` should be `vCPU`?
Also, English grammar agreement is funny: `neither` needs to agree with
`nor`, but the two do
On Mon, Jul 01, 2019 at 08:05:24AM +0200, Sam Ravnborg wrote:
> Hi Oleksandr
>
> > > --- a/drivers/gpu/drm/xen/xen_drm_front.h
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front.h
> > > @@ -11,13 +11,19 @@
> > > #ifndef __XEN_DRM_FRONT_H_
> > > #define __XEN_DRM_FRONT_H_
> > > -#include
> > > -#in
Juergen Gross writes:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporting PVH officially since version 2.04 th
%cr8 is an alias of APIC_TASKPRI, which is handled by
lapic_{suspend,resume}() with the rest of the Local APIC state. Saving
and restoring the TPR state in isolation is not a clever idea.
Drop it all.
While editing wakeup_prot.S, trim its include list to just the headers
which are used, which is
Hi,
On 15/07/2019 10:17, Paul Durrant wrote:
The _PGC_allocated flag is set on a page when it is assigned to a domain
along with an initial reference count of at least 1. To clear this
'allocation' reference it is necessary to test-and-clear _PGC_allocated and
then only drop the reference if the
Hi,
On 10/07/2019 05:57, Viktor Mitin wrote:
Update ARM code coverage warning about testing gcov on arm
Signed-off-by: Viktor Mitin
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:/
On 15/07/2019 18:26, Julien Grall wrote:
> Hi,
>
> On 10/07/2019 05:57, Viktor Mitin wrote:
>> Update ARM code coverage warning about testing gcov on arm
>>
>> Signed-off-by: Viktor Mitin
>
> Acked-by: Julien Grall
Docs parts Acked-by: Andrew Cooper
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>
> Juergen Gross writes:
>
> > The long term plan has been to replace Xen PV guests by PVH. The first
> > victim of that plan are now 32-bit PV guests, as those are used only
> > rather seldom these days. Xen on x86 requires 64-bit support and wi
On 15/07/2019 18:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom these d
On 15.07.19 19:28, Andy Lutomirski wrote:
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
Juergen Gross writes:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86
On Mon, 2019-07-15 at 14:52 +, Jan Beulich wrote:
> On 15.07.2019 16:42, George Dunlap wrote:
> > On 7/15/19 3:23 PM, Jan Beulich wrote:
> > > On 15.07.2019 16:11, George Dunlap wrote:
> > > > There was a long discussion about security patches, with the
> > > > general
> > > > proposal being th
On Mon, 2019-07-15 at 14:59 +0100, George Dunlap wrote:
> Looking through the notes, it seems like the first part of this
> discussion, re hypervisor upgrade / downgrade & libraries, was partly
> covered in the distro session, in which Debian's Xen version co-
> install
> was discussed and found us
Hi Viktor,
On 20/06/2019 11:38, Viktor Mitin wrote:
Functions make_timer_node and make_timer_domU_node are quite similar.
The only difference between Dom0 and DomU timer DT node
is the timer interrupts used. All the rest code should be the same.
This is a bit confusing to read. First you say
Some numpty (me) forgot to organise a scribe for the session, so these
notes are from memory. As a result, all aspects are up for argumen^W
debate.
We started by discussing Core-aware scheduling, and covering the point
that while in principle it makes an attackers life easier, it doesn't
make a d
Hi Julien,
Julien Grall writes:
> At the moment, the user should save x30/lr if it cares about it.
>
> Follow-up patches will introduce more use of putn in place where lr
> should be preserved.
>
> Furthermore, any user of putn should also move the value to register x0
> if it was stored in a dif
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-> for live migration: domid is a problem in this case
-> randomize and pray does not work on smaller fleets
-> this is not a probl
flight 139004 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-i386-qemu
flight 139003 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 133580
test-amd64
flight 139016 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139016/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 163feb2e45cd088e65da1ff395dc3293065a4603
baseline version:
freebsd 5c4a9b0e32c
flight 139011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139011/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eebc135ffb210c6da7133145ba9e5423cafc13d4
baseline version:
ovmf 70565e64227dfa254d8a0
flight 139010 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 138915
test-amd64-amd64-xl-qemut-win7-amd64
flight 139014 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 138977
test-armhf-armhf-
On 15.07.19 21:31, Sarah Newman wrote:
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-> for live migration: domid is a problem in this case
-> randomize and pray does not work on smaller fleets
->
On 15.07.19 17:44, Boris Ostrovsky wrote:
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 084de77a109e..d42737f31304 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o
1 - 100 of 103 matches
Mail list logo
