[Xen-devel] [linux-4.9 test] 117637: tolerable FAIL - PUSHED

flight 117637 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117637/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117255 test-amd64-i386-xl-qemut-win7-amd64 17

Re: [Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

On 1/5/18 10:43 AM, Roger Pau Monne wrote: > When using a linker that supports both formats the following error > will be triggered: > > efi/buildid.o: file not recognized: File format is ambiguous > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 > > Solve this by specifying the

[Xen-devel] [qemu-mainline test] 117633: regressions - trouble: broken/fail/pass

flight 117633 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/117633/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm broken test-amd64-amd64-libvirt-vhd

Re: [Xen-devel] Dynamic Disassembling domU Instructions

Hi Jan, Thank you for the insight. That explains a lot of the repeated cached instruction fetching. This might belong to another thread, I was exploring xentrace, ran it with "sudo xentrace output", but it returns the message of "ERROR: Failed to map cpu buffer! (13 = Permission denied)", even

[Xen-devel] [xen-unstable-smoke test] 117663: tolerable all pass - PUSHED

flight 117663 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117663/ 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

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/05/2018 11:10 AM, Kevin Stange wrote: > On 01/04/2018 03:16 PM, Kevin Stange wrote: >> On 01/04/2018 06:52 AM, Anthony PERARD wrote: >>> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote: On 01/03/2018 11:57 AM, Anthony PERARD wrote: > On Wed, Dec 20, 2017 at 11:40:03AM

[Xen-devel] [libvirt test] 117631: regressions - trouble: broken/fail/pass

flight 117631 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/117631/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair broken test-amd64-amd64-libvirt-pair 4

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 05/01/18 18:16, Rich Persaud wrote: >> On Jan 5, 2018, at 06:35, Lars Kurth > > wrote: >> SP2 can be mitigated in two ways, both of which essentially prevent >> speculative execution of indirect branches. The first is to flush the >>

[Xen-devel] [xen-4.8-testing test] 117628: trouble: broken/fail/pass

flight 117628 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117628/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 broken

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 3 Information leak via side effects of speculative execution UPDATES IN VERSION 3 Add information

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

> On Jan 5, 2018, at 06:35, Lars Kurth wrote: > > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for > xen-users/xen-devel. If you have questions, please reply to this thread and > we will try and improve the FAQ

Re: [Xen-devel] [PATCH RFC v1 36/74] --- x86/shim: Kconfig and command line options

On 05/01/18 15:26, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -133,6 +133,28 @@ config PVH_GUEST >> ---help--- >>Support booting using the PVH ABI. >> >> + If unsure, say N. >> +

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

> On 5 Jan 2018, at 15:55, Hans van Kranenburg wrote: > > On 01/05/2018 12:35 PM, Lars Kurth wrote: >> Hi all, this is a repost of >> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ >>

Re: [Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution

I'm just adding some comments below on some updates that might be helpful to add to help clarify things for interested parties. These comments are driven purely based on the questions that I've had to field from others. - Since this advisory talks about 3 CVEs and then breaks the issue into 3

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/04/2018 03:16 PM, Kevin Stange wrote: > On 01/04/2018 06:52 AM, Anthony PERARD wrote: >> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote: >>> On 01/03/2018 11:57 AM, Anthony PERARD wrote: On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote: > Hi, > >

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

On 01/05/2018 03:03 AM, Paul Durrant wrote: >> -Original Message- >> From: Kevin Stange [mailto:ke...@steadfast.net] >> Sent: 04 January 2018 21:17 >> To: Paul Durrant >> Cc: George Dunlap ; xen- >> de...@lists.xenproject.org; Anthony

[Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

When using a linker that supports both formats the following error will be triggered: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Solve this by specifying the buildid.o format to pe-x86-64. Signed-off-by: Roger Pau Monné

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 01/05/2018 12:35 PM, Lars Kurth wrote: > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > for xen-users/xen-devel. If you have questions, please reply to this > thread and we will try and improve the FAQ based on questions. > Regards Lars

[Xen-devel] [linux-linus test] 117623: regressions - trouble: broken/fail/pass

flight 117623 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117623/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm broken

Re: [Xen-devel] [PATCH 2/2] x86/svm: Add checks for nested HW features

On Fri, Dec 22, 2017 at 03:15:48PM +, Andrew Cooper wrote: > Unfortunately, nestedhvm_enabled() is guaranteed to be false at the > point that construct_vmcb() is called (due the order in which > information appears while constructing the VM), which means we will > never enable these

Re: [Xen-devel] [PATCH RFC v1 36/74] --- x86/shim: Kconfig and command line options

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -133,6 +133,28 @@ config PVH_GUEST > ---help--- > Support booting using the PVH ABI. > > + If unsure, say N. > + > +config PV_SHIM > + def_bool n > +

Re: [Xen-devel] [PATCH RFC v1 34/74] x86/guest: add PV console code

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/drivers/char/xen_pv_console.c > @@ -0,0 +1,198 @@ > +/** > + * drivers/char/xen_pv_console.c > + * > + * A frontend driver for Xen's PV

Re: [Xen-devel] [PATCH RFC v1 33/74] x86/guest: enable event channels upcalls

On 05/01/18 15:07, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> @@ -30,6 +31,7 @@ >> bool xen_guest; >> >> static uint32_t xen_cpuid_base; >> +static uint8_t evtchn_upcall_vector; > There being a single global vector, why do you use >

Re: [Xen-devel] [PATCH RFC v1 33/74] x86/guest: enable event channels upcalls

>>> On 04.01.18 at 14:05, wrote: > @@ -30,6 +31,7 @@ > bool xen_guest; > > static uint32_t xen_cpuid_base; > +static uint8_t evtchn_upcall_vector; There being a single global vector, why do you use HVMOP_set_evtchn_upcall_vector instead of setting HVM_PARAM_CALLBACK_IRQ?

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

Julien, > On 5 Jan 2018, at 14:40, Julien Grall wrote: > > (apologies for the formatting) > > Hi Lars, > > Thank you for putting together an FAQ. > > Few comments below around Arm. > > Systems running Xen, like all operating systems and hypervisors, are >

Re: [Xen-devel] [PATCH RFC v1 32/74] x86: don't swallow the first command line item in pvh mode

>>> On 04.01.18 at 14:05, wrote: > @@ -632,11 +633,10 @@ static char * __init cmdline_cook(char *p, const char > *loader_name) > while ( *p == ' ' ) > p++; > > -/* GRUB2 does not include image name as first item on command line. */ > -if (

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On 05/01/18 14:28, Roger Pau Monné wrote: > On Fri, Jan 05, 2018 at 02:20:16PM +, Andrew Cooper wrote: >> On 05/01/18 14:11, Jan Beulich wrote: >> On 04.01.18 at 14:05, wrote: --- a/xen/arch/x86/guest/xen.c +++ b/xen/arch/x86/guest/xen.c @@ -72,6 +72,30

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

(apologies for the formatting) Hi Lars, Thank you for putting together an FAQ. Few comments below around Arm. On 5 Jan 2018 13:37, "Lars Kurth" wrote: Hi all, this is a repost of https://blog.xenproject.org/ 2018/01/04/xen-project-spectremeltdown-faq/ for

Re: [Xen-devel] [PATCH RFC v1 30/74] x86: APIC timer calibration when running as a guest

>>> On 04.01.18 at 14:05, wrote: > The timer calibration depends on the number of ticks. Introduce a > variant to wait for a tick when running as a guest. The change itself is fine, i.e. Reviewed-by: Jan Beulich but the description (to me, but it may be

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/18 14:27, Jan Beulich wrote: On 05.01.18 at 15:11, wrote: >> Here's a question: What if we didn't try to prevent the guest from >> reading hypervisor memory at all, but instead just tried to make sure >> that there was nothing of interest there? >> >> If

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On Fri, Jan 5, 2018 at 2:17 PM, Juergen Gross wrote: > On 05/01/18 15:11, George Dunlap wrote: >> On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: >>> On 05/01/18 10:26, Andrew Cooper wrote: On 05/01/2018 07:48, Juergen Gross wrote: > On 04/01/18

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On Fri, Jan 05, 2018 at 02:20:16PM +, Andrew Cooper wrote: > On 05/01/18 14:11, Jan Beulich wrote: > On 04.01.18 at 14:05, wrote: > >> --- a/xen/arch/x86/guest/xen.c > >> +++ b/xen/arch/x86/guest/xen.c > >> @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) > >>

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

>>> On 05.01.18 at 15:21, wrote: > We already have map_domain_page(), as a result of 32-bit mode and >>5TiB mode, so getting the domain pages out of the HV should be pretty > easy. E.g. by doing away with the directmap altogether. Jan

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

>>> On 05.01.18 at 15:11, wrote: > Here's a question: What if we didn't try to prevent the guest from > reading hypervisor memory at all, but instead just tried to make sure > that there was nothing of interest there? > > If sensitive information pertaining to a given vcpu

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

On 05/01/18 14:11, Jan Beulich wrote: On 04.01.18 at 14:05, wrote: >> --- a/xen/arch/x86/guest/xen.c >> +++ b/xen/arch/x86/guest/xen.c >> @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) >> xen_guest = true; >> } >> >> +static void map_shared_info(struct

Re: [Xen-devel] [PATCH RFC v1 29/74] x86: xen pv clock time source

>>> On 04.01.18 at 14:05, wrote: > It is a variant of TSC clock source. > > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper > Signed-off-by: Roger Pau Monné Mostly fine, with the TODO addressed,

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/18 15:11, George Dunlap wrote: > On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: >> On 05/01/18 10:26, Andrew Cooper wrote: >>> On 05/01/2018 07:48, Juergen Gross wrote: On 04/01/18 21:21, Andrew Cooper wrote: > This work was developed as an SP3 mitigation,

Re: [Xen-devel] [PATCH v2 5/6] xen: Add only xen-sysdev to dynamic sysbus device list

On Sat, Nov 25, 2017 at 01:16:09PM -0200, Eduardo Habkost wrote: > There's no need to make the machine allow every possible sysbus > device. We can now just add xen-sysdev to the allowed list. > > Cc: Stefano Stabellini > Cc: Anthony Perard >

Re: [Xen-devel] [PATCH RFC v1 28/74] x86: initialise shared_info page

>>> On 04.01.18 at 14:05, wrote: > --- a/xen/arch/x86/guest/xen.c > +++ b/xen/arch/x86/guest/xen.c > @@ -72,6 +72,30 @@ void __init probe_hypervisor(void) > xen_guest = true; > } > > +static void map_shared_info(struct e820map *e820) > +{ > +paddr_t frame =

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross wrote: > On 05/01/18 10:26, Andrew Cooper wrote: >> On 05/01/2018 07:48, Juergen Gross wrote: >>> On 04/01/18 21:21, Andrew Cooper wrote: This work was developed as an SP3 mitigation, but shelved when it became clear

Re: [Xen-devel] [PATCH RFC v1 27/74] xen/console: Introduce console=xen

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > This specifies whether to use Xen specific console output. There are > two variants: one is the hypervisor console, the other is the magic > debug port 0xe9. With just x86 in mind this is

Re: [Xen-devel] [PATCH RFC v1 24/74] x86/guest: Hypercall support

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/arch/x86/guest/hypercall_page.S > @@ -0,0 +1,79 @@ > +#include > +#include > +#include > + > +.section ".text.page_aligned", "ax", @progbits > +.p2align PAGE_SHIFT > + > +GLOBAL(hypercall_page) >

Re: [Xen-devel] [PATCH v1] x86/mm: Supresses vm_events caused by page-walks

On 10/30/2017 07:38 PM, Tamas K Lengyel wrote: > On Mon, Oct 30, 2017 at 11:19 AM, Razvan Cojocaru > wrote: >> On 10/30/2017 07:07 PM, Tamas K Lengyel wrote: >>> On Mon, Oct 30, 2017 at 11:01 AM, Razvan Cojocaru >>> wrote: On 10/30/2017

Re: [Xen-devel] [PATCH RFC v1 23/74] x86/entry: Probe for Xen early during boot

>>> On 04.01.18 at 14:05, wrote: > --- /dev/null > +++ b/xen/arch/x86/guest/xen.c > @@ -0,0 +1,75 @@ > +/** > + * arch/x86/guest/xen.c > + * > + * Support for detecting and running under Xen. > + * >

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 01/05/2018 11:35 AM, Lars Kurth wrote: > Hi all, this is a repost of > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for > xen-users/xen-devel. If you have questions, please reply to this thread and > we will try and improve the FAQ based on questions. I also

[Xen-devel] [xen-unstable test] 117617: regressions - trouble: broken/fail/pass

flight 117617 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117617/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken test-amd64-amd64-xl-qcow2

Re: [Xen-devel] [PATCH RFC v1 20/74] x86: produce a binary that can be booted as PVH

>>> On 04.01.18 at 14:05, wrote: > Signed-off-by: Wei Liu > Signed-off-by: Andrew Cooper Again I assume a description is still being intended to be written > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@

[Xen-devel] Xen Project Spectre/Meltdown FAQ

Hi all, this is a repost of https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have questions, please reply to this thread and we will try and improve the FAQ based on questions. Regards Lars Google’s Project Zero announced several

Re: [Xen-devel] [PATCH RFC v1 19/74] x86: introduce ELFNOTE macro

>>> On 04.01.18 at 14:05, wrote: > It is needed later for introducing PVH entry point. Perhaps worth moving the addition there, rather than introducing dead code here? > --- a/xen/include/asm-x86/asm_defns.h > +++ b/xen/include/asm-x86/asm_defns.h > @@ -409,4 +409,16 @@

Re: [Xen-devel] [PATCH RFC v1 18/74] x86/link: Relocate program headers

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > When the xen binary is loaded by libelf (in the future) we rely on the > elf loader to load the binary accordingly. It would really help if it was said here what effect this has on the

Re: [Xen-devel] [PATCH RFC v1 17/74] ---- x86/Kconfig: Options for Xen and PVH support

>>> On 04.01.18 at 14:05, wrote: Please drop the stray from the subject. > From: Andrew Cooper > > Signed-off-by: Andrew Cooper No description (rationale) at all? But perhaps that's to be attributed to the RFC

Re: [Xen-devel] [PATCH RFC v1 10/74] x86/time: Print a more helpful error when a platform timer can't be found

>>> On 04.01.18 at 14:05, wrote: > From: Andrew Cooper > > Signed-off-by: Andrew Cooper > Reviewed-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 05 January 2018 10:29 > To: Paul Durrant > Cc: JulienGrall ; Andrew Cooper > ; George Dunlap > ; Ian Jackson

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

>>> On 05.01.18 at 11:16, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Paul Durrant >> Sent: 03 January 2018 16:48 >> Ok, thanks. If change back to having the pages owned by the tools domain >> then I guess this will all be

Re: [Xen-devel] Xen 4.11 Development Update

> -Original Message- > From: Juergen Gross [mailto:jgr...@suse.com] > Sent: 05 January 2018 09:17 > To: xen-devel@lists.xenproject.org > Cc: jgr...@suse.com > Subject: Xen 4.11 Development Update > > This email only tracks big items for xen.git tree. Please reply for items you > would

Re: [Xen-devel] Xen 4.11 Development Update

>>> On 05.01.18 at 10:57, wrote: > On 05/01/18 10:32, Jan Beulich wrote: >> Another x86 item are the emulator additions to support post-AVX >> insns and some other, earlier ones we don't have support for >> yet. The main parts of that series have now been pending review >> for

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 03 January 2018 16:48 > To: 'Jan Beulich' > Cc: StefanoStabellini ; Wei Liu > ; Andrew Cooper

Re: [Xen-devel] Xen 4.11 Development Update

On 05/01/18 10:32, Jan Beulich wrote: On 05.01.18 at 10:16, wrote: >> === x86 === >> >> * Enable Memory Bandwidth Allocation in Xen (v10) >> - XEN-48 >> - Yi Sun >> >> * guest resource mapping (v17) >> - Paul Durrant >> >> * vNVDIMM support for HVM guest (RFC

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/2018 09:39, Juergen Gross wrote: > On 05/01/18 10:26, Andrew Cooper wrote: >> On 05/01/2018 07:48, Juergen Gross wrote: >>> On 04/01/18 21:21, Andrew Cooper wrote: This work was developed as an SP3 mitigation, but shelved when it became clear that it wasn't viable to get

Re: [Xen-devel] Xen 4.11 Development Update

Hello Juergen, On 5 January 2018 at 14:46, Juergen Gross wrote: > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.11 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide

Re: [Xen-devel] Dynamic Disassembling domU Instructions

>>> On 05.01.18 at 04:17, wrote: > I am trying to modify Xen 4.8 to have it print out the opcode as well as > some registers of an HVM domU as it runs. I tried to modify > xen/arch/x86/hvm/emulate.c 's hvmemul_insn_fetch to output the content in > hvmemul_ctxt->insn_buf

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On 05/01/2018 07:48, Juergen Gross wrote: > On 04/01/18 21:21, Andrew Cooper wrote: >> This work was developed as an SP3 mitigation, but shelved when it became >> clear >> that it wasn't viable to get done in the timeframe. >> >> To protect against SP3 attacks, most mappings needs to be flushed

[Xen-devel] Xen 4.11 Development Update

This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.11 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

> -Original Message- > From: Kevin Stange [mailto:ke...@steadfast.net] > Sent: 04 January 2018 21:17 > To: Paul Durrant > Cc: George Dunlap ; xen- > de...@lists.xenproject.org; Anthony Perard > Subject: Re:

[Xen-devel] Ping: [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

Any thoughts appreciated. On Vi, 2017-10-06 at 13:02 +0300, Alexandru Isaila wrote: > This patch adds the hvm_save_one_cpu_ctxt() function. > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save > callbacks where only data for one VCPU is required. > > Signed-off-by: Alexandru Isaila

[Xen-devel] [PATCH] xen-netfront: enable device after manual module load

When loading the module after unloading it, the network interface would not be enabled and thus wouldn't have a backend counterpart and unable to be used by the guest. The guest would face errors like: [root@guest ~]# ethtool -i eth0 Cannot get driver information: No such device