flight 139318 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139318/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7d0a56c4a125917a474d3469f774184d09a38f48
baseline version:
ovmf
flight 139310 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139310/
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. 139259
Tests which did
flight 139307 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 139286
Tests which did
From: Christopher Clark
gcc 9.1.0 reports:
| test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
nul-terminated string [-Werror=format-overflow=]
|64 | fail(" Test '%.12s', expected vendor %u, got %u\n",
| |
flight 139306 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
On 7/24/19 10:08 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/xen/xen-pciback/conf_space_capability.c: In function pm_ctrl_write:
> drivers/xen/xen-pciback/conf_space_capability.c:119:25: warning:
> variable old_state set but not used
On Tue, Jul 16, 2019 at 07:40:57AM +, Jan Beulich wrote:
> In line with "x86/IRQ: desc->affinity should strictly represent the
> requested value" the internally used IRQ(s) also shouldn't be restricted
> to online ones. Make set_desc_affinity() (set_msi_affinity() then does
> by implication)
On Tue, Jul 16, 2019 at 12:01:11PM +, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch aims to clear the IOMMU hap share support as it will not be
> used in the future. By doing this the IOMMU bits used in pte[52:58] can
> be used in
On Tue, Jul 16, 2019 at 12:01:15PM +, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch cleans the unreachable code garded by iommu_hap_pt_share.
>
> [1] c2ba3db31ef2d9f1e40e7b6c16cf3be3d671d555
>
> Signed-off-by: Alexandru Isaila
flight 139309 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139309/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd d78b126a34dc1b5c6830bf18ddae6f5b2990f589
baseline version:
freebsd
On 24/07/2019 19:02, Oleg Ginzburg wrote:
> Hello maillist,
>
> I use XEN on the FreeBSD platform. Everything worked fine until I
> needed to use nested virtualization (for testing purposes).
>
> After some communication with Roger Pau Monné, maintainer of XEN port
> in FreeBSD (
On 24/07/2019 18:42, Andrew Cooper wrote:
> This is all trivial cleanup spotted after having come collisions in the
> XenServer patchqueue when rebasing over Rogers PCI SBDF changes in staging.
/sigh and further looking through dmi_scan.c has revealed that
dmi_save_ident() leaks all of the
Hello maillist,
I use XEN on the FreeBSD platform. Everything worked fine until I
needed to use nested virtualization (for testing purposes).
After some communication with Roger Pau Monné, maintainer of XEN port
in FreeBSD ( https://www.freshports.org/emulators/xen-kernel ) it was
suggested
This quirk doesn't change anything in Xen, and the web page doesn't exist.
The wayback machine confirms that the link disappeared somewhere between
2003-06-14 and 2004-07-07.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/dmi_scan.c | 15
At 17:06 +0100 on 23 Jul (1563901567), Paul Durrant wrote:
> The flag is not needed since the domain 'createflags' can now be tested
> directly.
>
> Signed-off-by: Paul Durrant
Acked-by: Tim Deegan
though some of this change seems to have got into patch 3, maybe they
were reordered at some
> On Jul 19, 2019, at 15:31, Roman Shaposhnik wrote:
>
> Hi!
>
> we're using Xen on Advantech ARK-2250 Embedded Box PC:
>
> https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
Roman,
Good to see Xen being used on fanless
All DMI quirks tables are mutable, but are only ever read.
Update dmi_check_system() and dmi_system_id.callback to pass a const pointer,
and move all quirks tables into __initconst.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
This option is hardcoded to 1, and the #ifdef-ary doesn't exclude wakeup.S,
which makes it useless code noise.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
An alternative would be to wire it into Kconfig properly and properly exclude
wakeup.S, but that is
dmi_check_system() returns the number of matches. This being nonzero is more
efficient than calling into a trivial function to modify a variable.
No functional change, but this results in less compiled code, which is
also (fractionally) quicker to run.
Signed-off-by: Andrew Cooper
---
CC: Jan
This is all trivial cleanup spotted after having come collisions in the
XenServer patchqueue when rebasing over Rogers PCI SBDF changes in staging.
Andrew Cooper (3):
x86: Drop CONFIG_ACPI_SLEEP
x86/dmi: Drop trivial callback functions
x86/dmi: Constify quirks data
flight 139315 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139315/
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
flight 139300 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139300/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139277
test-armhf-armhf-libvirt 14
On Wed, 2019-07-24 at 17:35 +0200, Roger Pau Monné wrote:
> OK, I assumed the question was about reading the CPU temperature and
> then changing the frequency of the CPU, but not related to T-states.
Yes, the question is about reading the CPU temperature, How to change
it is already "solved" (we
> On Jul 23, 2019, at 17:05, Roman Shaposhnik wrote:
>
>> On Tue, Jul 23, 2019 at 2:00 PM Pasi Kärkkäinen wrote:
>>
>> Hi,
>>
>>> On Fri, Jul 19, 2019 at 02:23:44PM +, Jan Beulich wrote:
>>> All,
>>>
>>> the release is due in early August. Please point out backports you
>>> find missing
On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > > + // error
On Wed, 24 Jul 2019 14:34:55 +
Stewart Hildebrand wrote:
Hi,
I am afraid this is not enough. In your repo you hack the DT to contain
the reg-shift and io-width properties, but those are not part of the
"brcm,bcm2835-aux-uart" binding. Using 32-bit accesses is an integral
property of this
(+ Andre)
Hi Stewart,
On 24/07/2019 15:34, Stewart Hildebrand wrote:
Signed-off-by: Stewart Hildebrand
---
xen/drivers/char/ns16550.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e518f2d790..c8d7c9b710 100644
---
On 16.07.2019 14:01, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch cleans the unreachable code garded by iommu_hap_pt_share.
>
> [1] c2ba3db31ef2d9f1e40e7b6c16cf3be3d671d555
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Jan
On 16.07.2019 14:01, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch aims to clear the IOMMU hap share support as it will not be
> used in the future. By doing this the IOMMU bits used in pte[52:58] can
> be used in other ways.
>
> [1]
On 24.07.2019 17:35, Roger Pau Monné wrote:
> On Wed, Jul 24, 2019 at 02:47:19PM +, Jan Beulich wrote:
>> On 24.07.2019 16:36, Roger Pau Monné wrote:
>>> On Wed, Jul 24, 2019 at 10:01:40AM -0400, Fredy P. wrote:
My objective is to get CPU frequency throttling based on the
On Wed, Jul 24, 2019 at 11:25:55AM -0400, Fredy P. wrote:
> Hello, answering between lines
> On Wed, 2019-07-24 at 16:36 +0200, Roger Pau Monné wrote:
> > On Wed, Jul 24, 2019 at 10:01:40AM -0400, Fredy P. wrote:
> > > If the answer for first question is not, then there is any way to
> > > get
> >
On Wed, Jul 24, 2019 at 02:47:19PM +, Jan Beulich wrote:
> On 24.07.2019 16:36, Roger Pau Monné wrote:
> > On Wed, Jul 24, 2019 at 10:01:40AM -0400, Fredy P. wrote:
> >> My objective is to get CPU frequency throttling based on the
> >> temperature in a Xen/OpenWRT(dom0) system.
> >>
> >>
On 16.07.2019 12:16, Paul Durrant wrote:
> +int iommu_get_device_group(struct domain *d, pci_sbdf_t sbdf,
> + XEN_GUEST_HANDLE_64(uint32) buf,
> + unsigned int max_sdevs)
> +{
> +struct iommu_group *grp = NULL;
> +struct pci_dev *pdev;
>
flight 139296 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139296/
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
Tests which are
--
Fredy Pulido,
Consultant en logiciel libre
Infrastructure, Infonuagique et architecture de systèmes
Savoir-faire Linux, Montréal, Qc
Bureau : (+ 1) 514 276-5468 p.410
Message de confidentialité :
Ce courriel (de même que les fichiers joints) est strictement réservé à l'usage
de la personne
On Wed, 24 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 24/07/2019 01:17, Stefano Stabellini wrote:
> > On Thu, 18 Jul 2019, Julien Grall wrote:
> > > With that, the patch 1191156361 "xen/arm: fix mask calculation in
> > > pdx_init_mask" could be re-instated.
> > > ---
> > >
On 16.07.2019 14:20, Paul Durrant wrote:
>> From: Roger Pau Monne
>> Sent: 16 July 2019 12:28
>>
>> On Tue, Jul 16, 2019 at 11:16:57AM +0100, Paul Durrant wrote:
>>> @@ -81,6 +85,48 @@ int iommu_group_assign(struct pci_dev *pdev, void *arg)
>>> return 0;
>>> }
>>>
>>> +int
On Wednesday, July 24, 2019 10:47 AM, Julien Grall wrote:
>Hi,
>
>Thank you for your series. Please use git-send-email so your series is threaded
>correctly and sent in plain text (not HTML!).
My apologies. I will do this next time I have something to send.
>I guess you are not using Andre's
On 24.07.19 16:54, Sergey Dyasli wrote:
On 24/07/2019 10:13, Juergen Gross wrote:
The fix is a one-liner. :-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index f0bc5b3161..da9efb147f 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -2207,6 +2207,7 @@ static
flight 139301 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139301/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 83e7d5c75e7304aa5172c88eb24fa563445ce043
baseline version:
ovmf
On 24.07.2019 16:36, Roger Pau Monné wrote:
> On Wed, Jul 24, 2019 at 10:01:40AM -0400, Fredy P. wrote:
>> My objective is to get CPU frequency throttling based on the
>> temperature in a Xen/OpenWRT(dom0) system.
>>
>> After to expend hours reading Xen's wiki, mailing list archives,
>> commits,
On 24/07/2019 10:13, Juergen Gross wrote:
> The fix is a one-liner. :-)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index f0bc5b3161..da9efb147f 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -2207,6 +2207,7 @@ static struct sched_unit
>
Hi,
On 24/07/2019 15:34, Stewart Hildebrand wrote:
Signed-off-by: Stewart Hildebrand
No more earlyprintk alias. Instead, this needs to go in the board documentation.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Hi,
Thank you for your series. Please use git-send-email so your series is threaded
correctly and sent in plain text (not HTML!).
On 24/07/2019 15:34, Stewart Hildebrand wrote:
This is a series to enable printk and UART console for Raspberry Pi 4.
I have been able to get Xen+dom0+domUs
flight 139303 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139303/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139193
test-armhf-armhf-libvirt-raw 13
On Wed, Jul 24, 2019 at 10:01:40AM -0400, Fredy P. wrote:
> Hello,
>
> My objective is to get CPU frequency throttling based on the
> temperature in a Xen/OpenWRT(dom0) system.
>
> After to expend hours reading Xen's wiki, mailing list archives,
> commits, googling and asking in the IRC channel
Signed-off-by: Stewart Hildebrand
---
xen/drivers/char/ns16550.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e518f2d790..c8d7c9b710 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1611,6 +1611,7 @@
This is a series to enable printk and UART console for Raspberry Pi 4.
I have been able to get Xen+dom0+domUs booting. Tested with Xen 4.12 and Linux
4.19.y (Raspberry Pi linux tree + a couple of patches). Please see [1] for
build instructions and limitations.
Andre - it appears that we each
Signed-off-by: Stewart Hildebrand
---
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 1 +
2 files changed, 2 insertions(+)
diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 89e081e51e..8af5a90695 100644
--- a/docs/misc/arm/early-printk.txt
On 16.07.2019 12:16, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/Makefile
> +++ b/xen/drivers/passthrough/Makefile
> @@ -4,6 +4,7 @@ subdir-$(CONFIG_X86) += x86
> subdir-$(CONFIG_ARM) += arm
>
> obj-y += iommu.o
> +obj-$(CONFIG_HAS_PCI) += groups.o
I assume this dependency on PCI is
On Tue, Jul 23, 2019 at 10:32:26AM -0700, Roman Shaposhnik wrote:
> Hi Roger!
>
> I applied your patch, removed no-igfx and I still see the original
> problem. Please let me know what other logs/debugs would you need at
> this point.
I'm not sure why you don't get the rmrrs added to the iommu
On 16.07.2019 12:16, 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 also done
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/xen/xen-pciback/conf_space_capability.c: In function pm_ctrl_write:
drivers/xen/xen-pciback/conf_space_capability.c:119:25: warning:
variable old_state set but not used [-Wunused-but-set-variable]
It is never used so can be removed.
Hello,
My objective is to get CPU frequency throttling based on the
temperature in a Xen/OpenWRT(dom0) system.
After to expend hours reading Xen's wiki, mailing list archives,
commits, googling and asking in the IRC channel I'm coming here asking
for help because I hope there is something I miss
> -Original Message-
> From: Jan Beulich
> Sent: 24 July 2019 14:41
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Brian Woods ;
> Suravee Suthikulpanit
> ; Andrew Cooper ;
> Kevin Tian
> ; Wei Liu
> Subject: Re: [PATCH v3 1/4] iommu / x86: move call to scan_pci_devices()
On 16.07.2019 12:16, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -28,9 +28,15 @@ struct iommu_ops __read_mostly iommu_ops;
>
> int __init iommu_hardware_setup(void)
> {
> +int rc;
> +
> if ( !iommu_init_ops )
>
On Wed, 2019-07-24 at 10:32 +, Jan Beulich wrote:
> On 15.07.2019 17:46, George Dunlap wrote:
> > 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.
On 19/07/2019, 14:50, "Rich Persaud" wrote:
On Jul 19, 2019, at 09:31, Julien Grall wrote:
>> On 19/07/2019 14:24, Julien Grall wrote:
>> Hi Tamas,
>>> On 19/07/2019 14:14, Tamas K Lengyel wrote:
On Fri, Jul 19, 2019 at 7:11 AM Julien Grall
wrote:
On 24.07.2019 14:00, Jan Beulich wrote:
> On 23.07.2019 19:58, Roman Shaposhnik wrote:
>> No worries. Take a look at the head of the log attached.
>
> One more thing for you to tweak to make the log even more useful:
> As per
>
> (XEN) Xen version 4.12.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n
On 23.07.2019 19:58, Roman Shaposhnik wrote:
> No worries. Take a look at the head of the log attached.
One more thing for you to tweak to make the log even more useful:
As per
(XEN) Xen version 4.12.0 (@) (gcc (Alpine 6.4.0) 6.4.0) debug=n Tue Jul 23
17:15:48 UTC 2019
this is a non-debug
On 24.07.2019 13:04, Andrew Cooper wrote:
> On 24/07/2019 11:22, Jan Beulich wrote:
>> On 23.07.2019 21:58, Andrew Cooper wrote:
>>> All callers are in pv/iret.c. Move the function and make it static.
>>>
>>> Even before the pinning cleanup, there was nothing which is specific to
>>> operating on
On 24.07.19 13:38, Andrew Cooper wrote:
On 24/07/2019 12:26, Juergen Gross wrote:
pv_raise_interrupt() is only called for NMIs these days, so the MCE
specific part can be removed. Rename pv_raise_interrupt() to
pv_raise_nmi() and NMI_MCE_SOFTIRQ to NMI_SOFTIRQ.
Additionally there is no need to
On 24/07/2019 12:23, Andrew Cooper wrote:
> On 23/07/2019 18:32, Roman Shaposhnik wrote:
>> Oh, and it seems that that https://downloads.xenproject.org/ SSL
>> certificate expired yesterday -- perhaps somebody can take a look at
>> that.
> Thanks for reporting. It should be being taken care of.
On 24/07/2019 12:26, Juergen Gross wrote:
> pv_raise_interrupt() is only called for NMIs these days, so the MCE
> specific part can be removed. Rename pv_raise_interrupt() to
> pv_raise_nmi() and NMI_MCE_SOFTIRQ to NMI_SOFTIRQ.
>
> Additionally there is no need to pin the vcpu the NMI is delivered
Are there any guidance for this requirements?
Thank you!
-- Original --
From: "Ramble"<370909...@qq.com>;
Date: Mon, Jul 22, 2019 10:42 AM
To: "xen-devel";
Subject: [Xen ARM] Can I use xen tools lib on android domain U?
Hi xen-devel experts, Now I use
While trying to handle temporary vcpu pinnings in a sane way in my
core scheduling series I found a nice way to simplify the temporary
pinning cases.
I'm sending the two patches independently from my core scheduling
series as they should be considered even without core scheduling.
Changes in V2:
pv_raise_interrupt() is only called for NMIs these days, so the MCE
specific part can be removed. Rename pv_raise_interrupt() to
pv_raise_nmi() and NMI_MCE_SOFTIRQ to NMI_SOFTIRQ.
Additionally there is no need to pin the vcpu the NMI is delivered
to, that is a leftover of (already removed) MCE
Today there are two scenarios which are pinning vcpus temporarily to
a single physical cpu:
- wait_event() handling
- SCHEDOP_pin_override handling
Each of those cases are handled independently today using their own
temporary cpumask to save the old affinity settings.
The two cases can be
On 23/07/2019 18:32, Roman Shaposhnik wrote:
> Oh, and it seems that that https://downloads.xenproject.org/ SSL
> certificate expired yesterday -- perhaps somebody can take a look at
> that.
Thanks for reporting. It should be being taken care of.
~Andrew
On 24.07.19 12:07, Jan Beulich wrote:
On 23.07.2019 20:25, Juergen Gross wrote:
Today there are two scenarios which are pinning vcpus temporarily to
a single physical cpu:
- wait_event() handling
- vcpu_pin_override() handling
Each of those cases are handled independently today using their
Hi Stefano,
On 24/07/2019 01:17, Stefano Stabellini wrote:
On Thu, 18 Jul 2019, Julien Grall wrote:
With that, the patch 1191156361 "xen/arm: fix mask calculation in
pdx_init_mask" could be re-instated.
---
xen/arch/arm/mm.c| 2 ++
xen/include/asm-arm/mm.h | 6 --
2 files
Hi,
On 23/07/2019 18:55, Roman Shaposhnik wrote:
It would be great to have Xen running on RPi, but I have to wonder: is
it now possible to workaround RPi limitations of how GPU boots?
https://www.raspberrypi.org/forums/viewtopic.php?t=187086#p1206487
I thought that this is completely
On 24/07/2019 11:22, Jan Beulich wrote:
> On 23.07.2019 21:58, Andrew Cooper wrote:
>> All callers are in pv/iret.c. Move the function and make it static.
>>
>> Even before the pinning cleanup, there was nothing which is specific to
>> operating on curr, so rename the variable back to v.
> I'm
On 23.07.19 16:36, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien.
On 6/26/19 11:30 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection
functionalities
On 15.07.2019 17:46, George Dunlap wrote:
> 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
I
On 23.07.2019 21:58, Andrew Cooper wrote:
> All callers are in pv/iret.c. Move the function and make it static.
>
> Even before the pinning cleanup, there was nothing which is specific to
> operating on curr, so rename the variable back to v.
I'm not in full agreement with this: The implication
On 23.07.2019 20:25, Juergen Gross wrote:
> Today there are two scenarios which are pinning vcpus temporarily to
> a single physical cpu:
>
> - wait_event() handling
> - vcpu_pin_override() handling
>
> Each of those cases are handled independently today using their own
> temporary cpumask to
flight 139308 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139308/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 52fc4aaf1613e49d018bf3c5b1899b131ee2f417
baseline version:
xen
flight 139292 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139292/
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. 139259
Tests which did
On 23.07.2019 18:45, Andrew Cooper wrote:
> On 23/07/2019 17:09, Jan Beulich wrote:
>> On 23.07.2019 17:48, Roger Pau Monne wrote:
>>> Current code only prevents mapping the io-apic page into the guest
>>> physical memory map. Expand the range to be 0xFECx_ as described
>>> in the Intel 3
On 23.07.2019 22:59, Pasi Kärkkäinen wrote:
> I'd like to request backport of the following commit for 4.12.1:
>
> "libxl: fix pci device re-assigning after domain reboot":
> commitc19434d9284e93e6f9aaec9a70f5f361adbfaba6
>
>
On 22.07.19 16:22, Sergey Dyasli wrote:
On 19/07/2019 14:57, Juergen Gross wrote:
I have now a git branch with the two problems corrected and rebased to
current staging available:
github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
flight 139286 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
On 23.07.19 21:58, Andrew Cooper wrote:
All callers are in pv/iret.c. Move the function and make it static.
Even before the pinning cleanup, there was nothing which is specific to
operating on curr, so rename the variable back to v.
No functional change.
Signed-off-by: Andrew Cooper
From: Andrii Anisov
Fix the comment misprint, so it refers to the exact function name.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 9e16c16..8b78293 100644
---
85 matches
Mail list logo
