[Xen-devel] [ovmf test] 104054: all pass - PUSHED

flight 104054 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104054/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9fba84ac6ef01a0debf0cb823dd9eedb491bf1de baseline version: ovmf

[Xen-devel] [ovmf test] 104052: all pass - PUSHED

flight 104052 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104052/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 42b85551615d62fb68f0dbd63c068445c4d3c511 baseline version: ovmf

[Xen-devel] [PATCH] 16550: Add command line parsing adjustments

Add parsing options for reg_width and reg_shift in bootup command line parameters. This adds flexibility in setting register values for MMIO UART devices. Increase length of opt_com1 and opt_com2 buffer to accommodate more command line parameters. eg. com1=115200,8n1,0x3f8,4 (legacy IO) eg.

[Xen-devel] [PATCH RESEND] ns16550: Add command line parsing adjustments

Add parsing options for reg_width and reg_shift in bootup command line parameters. This adds flexibility in setting register values for MMIO UART devices. Increase length of opt_com1 and opt_com2 buffer to accommodate more command line parameters. eg. com1=115200,8n1,0x3f8,4 (legacy IO) eg.

[Xen-devel] [PATCH v2] ns16550: Add command line parsing adjustments

Add parsing options for reg_width and reg_shift in bootup command line parameters. This adds flexibility in setting register values for MMIO UART devices. Increase length of opt_com1 and opt_com2 buffer to accommodate more command line parameters. eg. com1=115200,8n1,0x3f8,4 (legacy IO) eg.

[Xen-devel] [qemu-mainline baseline-only test] 68325: regressions - FAIL

This run is configured for baseline tests only. flight 68325 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68325/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 9

[Xen-devel] [qemu-mainline test] 104049: tolerable FAIL - PUSHED

flight 104049 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104049/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 104044

[Xen-devel] [DOC v3] Xen transport for 9pfs

Changes in v3: - clarify a few statements - rename port- to event-channel- - use grant_ref_t ref[1] instead of ref[] Changes in v2: - fix copy/paste error - rename ring-ref- to ring-ref - fix memory barriers - add "verify prod/cons against local copy" - add a paragraph on high level design - add

Re: [Xen-devel] [RFC] netif: staging grants for requests

On Thu, 5 Jan 2017, Joao Martins wrote: > Hey Stefano, > > Thanks a lot for the review and the comments!! > > On 01/04/2017 07:40 PM, Stefano Stabellini wrote: > > On Wed, 14 Dec 2016, Joao Martins wrote: > >> # Proposed Extension > >> > >> ## Terminology > >> > >> `data gref` refers to the

[Xen-devel] [xen-unstable test] 104047: tolerable FAIL - PUSHED

flight 104047 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104047/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104040

[Xen-devel] [xen-unstable baseline-only test] 68323: regressions - FAIL

This run is configured for baseline tests only. flight 68323 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68323/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-boot

Re: [Xen-devel] [RFC PATCH v2 23/26] ARM: vITS: handle INVALL command

On Thu, 22 Dec 2016, Andre Przywara wrote: > The INVALL command instructs an ITS to invalidate the configuration > data for all LPIs associated with a given redistributor (read: VCPU). > This is nasty to emulate exactly with our architecture, so we just scan > the pending table and inject _every_

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

flight 104050 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104050/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v2] ns16550: Add command line parsing adjustments

On 05/01/17 22:39, Swapnil Paratey wrote: > Add parsing options for reg_width and reg_shift in bootup command line > parameters. This adds flexibility in setting register values > for MMIO UART devices. > > Increase length of opt_com1 and opt_com2 buffer to accommodate more > command line

Re: [Xen-devel] [PATCH 1/3] x86emul: support load forms of {, V}MOV{D, Q}

On 14/12/16 09:55, Jan Beulich wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -4995,6 +4995,12 @@ x86_emulate( > /* vmovntdq ymm,m256 */ > fail_if(ea.type != OP_MEM); > /* fall

Re: [Xen-devel] [RFC PATCH v2 13/26] ARM: vGICv3: Handle disabled LPIso

On Thu, 22 Dec 2016, Andre Przywara wrote: > If a guest disables an LPI, we do not forward this to the associated > host LPI to avoid queueing commands to the host ITS command queue. > So it may happen that an LPI fires nevertheless on the host. In this > case we can bail out early, but have to

Re: [Xen-devel] [RFC PATCH v2 12/26] ARM: vGICv3: handle virtual LPI pending and property tables

On Thu, 22 Dec 2016, Andre Przywara wrote: > Allow a guest to provide the address and size for the memory regions > it has reserved for the GICv3 pending and property tables. > We sanitise the various fields of the respective redistributor > registers and map those pages into Xen's address space

Re: [Xen-devel] [RFC PATCH v2 10/26] ARM: GICv3: forward pending LPIs to guests

On Thu, 22 Dec 2016, Andre Przywara wrote: > Upon receiving an LPI, we need to find the right VCPU and virtual IRQ > number to get this IRQ injected. > Iterate our two-level LPI table to find this information quickly when > the host takes an LPI. Call the existing injection function to let the >

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

On Wed, 4 Jan 2017, George Dunlap wrote: > The Xen Security Team has dealt with a number of issues recently where > it wasn't exactly clear whether we should issue an advisory or not: > the Xen Security Response Process only mentiones "'vulnerabilities", > without specifying what constitutes a

Re: [Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Thu, 22 Dec 2016, Andre Przywara wrote: > For the same reason that allocating a struct irq_desc for each > possible LPI is not an option, having a struct pending_irq for each LPI > is also not feasible. However we actually only need those when an > interrupt is on a vCPU (or is about to be

Re: [Xen-devel] [RFC PATCH v2 08/26] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

On Thu, 22 Dec 2016, Andre Przywara wrote: > To get MSIs from devices forwarded to a CPU, we need to name the device > and its MSIs by mapping them to an ITS. > Since this involves queueing commands to the ITS command queue, we can't > really afford to do this during the guest's runtime, as this

[Xen-devel] [ovmf baseline-only test] 68324: all pass

This run is configured for baseline tests only. flight 68324 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68324/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 74e2b93496778d3242fdb76d2f741365d79222a0 baseline

Re: [Xen-devel] [RFC] netif: staging grants for requests

Hey Stefano, Thanks a lot for the review and the comments!! On 01/04/2017 07:40 PM, Stefano Stabellini wrote: > On Wed, 14 Dec 2016, Joao Martins wrote: >> # Proposed Extension >> >> ## Terminology >> >> `data gref` refers to the reusable/staging grants, whereas `gref` are the >> ones that are

Re: [Xen-devel] [RFC] netif: staging grants for requests

On 01/04/2017 01:54 PM, Wei Liu wrote: > Hey! Hey! > Thanks for writing this detailed document! Thanks a lot for the review and comments! > > On Wed, Dec 14, 2016 at 06:11:12PM +, Joao Martins wrote: >> Hey, >> >> Back in the Xen hackaton '16 networking session there were a couple of ideas

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

On 01/05/2017 09:19 PM, Stefano Stabellini wrote: On Thu, 5 Jan 2017, Oleksandr Andrushchenko wrote: On 01/04/2017 08:23 PM, Stefano Stabellini wrote: On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote: First of all, thank you for comments You are welcome :-) On 01/04/2017 03:03 AM,

Re: [Xen-devel] [PATCH] x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C

Hi Ingo, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc2 next-20170105] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ingo-Molnar

Re: [Xen-devel] [PATCH] 16550: Add command line parsing adjustments

On 05/01/17 19:47, Swapnil Paratey wrote: > Add parsing options for reg_width and reg_shift in bootup command line > parameters. This adds flexibility in setting register values > for MMIO UART devices. > > Increase length of opt_com1 and opt_com2 buffer to accommodate more > command line

Re: [Xen-devel] [PATCH] xen: Fix build with older versions of GCC following e34bc403c3

On 01/05/2017 01:01 PM, Andrew Cooper wrote: > GCCs of at least 4.4 and earlier do not tollerate the initialisiation of the > $VENDOR_cpu_dev structures, because of c_ident becoming an anonymous union. > > Instead of using an anonymous union, reintepret c_ident[] in its CPUID form > just in

Re: [Xen-devel] [DOC v2] Xen transport for 9pfs

On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote: > If this is not too late for comments... > > On 12/06/2016 03:33 AM, Stefano Stabellini wrote: > > Changes in v2: > > - fix copy/paste error > > - rename ring-ref- to ring-ref > > - fix memory barriers > > - add "verify prod/cons against local

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

On Thu, Jan 05, 2017 at 03:16:53PM +0100, MasterPrenium wrote: > Hi Shaohua, > > Thanks for your reply. > > Let me explain my "huge". For example, if I'm making a low rate i/o stream, > I don't get a crash (<1MB written / sec) with random i/o, but if I'm making > a random I/O of about 20MB/sec,

[Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

Do not read a pci device's msi message data to see if a pirq was previously configured for the device's msi/msix, as the old pirq was unmapped and may now be in use by another pci device. The previous pirq should never be re-used; instead a new pirq should always be allocated from the hypervisor.

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

On Thu, 5 Jan 2017, Oleksandr Andrushchenko wrote: > On 01/04/2017 08:23 PM, Stefano Stabellini wrote: > > On Wed, 4 Jan 2017, Oleksandr Andrushchenko wrote: > > > First of all, thank you for comments > > You are welcome :-) > > > > > > > On 01/04/2017 03:03 AM, Stefano Stabellini wrote: > > > >

Re: [Xen-devel] [PATCH] x86emul: support fencing insns

On 14/12/16 09:37, Jan Beulich wrote: > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -5190,8 +5190,26 @@ x86_emulate( > case X86EMUL_OPC(0x0f, 0xae): case X86EMUL_OPC_66(0x0f, 0xae): /*

Re: [Xen-devel] [PATCH 2/3 v2] x86emul: conditionally clear BNDn for branches

On 05/01/17 09:13, Jan Beulich wrote: On 04.01.17 at 22:11, wrote: >> On 12/12/16 10:00, Jan Beulich wrote: >>> @@ -1791,6 +1795,34 @@ static int inject_swint(enum x86_swint_t >>> generate_exception(fault_type, error_code); >>> } >>> >>> +static void

Re: [Xen-devel] [RFC PATCH v2 07/26] ARM: GICv3 ITS: introduce host LPI array

On Thu, 22 Dec 2016, Andre Przywara wrote: 7> The number of LPIs on a host can be potentially huge (millions), > although in practise will be mostly reasonable. So prematurely allocating > an array of struct irq_desc's for each LPI is not an option. > However Xen itself does not care about LPIs,

[Xen-devel] [PATCH] x86/VMX: Implement vmptrst

Current codebase doesn't implement and use vmptrst. Implementing it as it may be required in future. Signed-off-by: Anshul Makkar --- xen/include/asm-x86/hvm/vmx/vmx.h | 22 ++ 1 file changed, 22 insertions(+) diff --git

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

flight 104048 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104048/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

On 01/05/2017 06:12 PM, Jan Beulich wrote: On 05.01.17 at 17:03, wrote: On 01/05/2017 05:45 PM, Jan Beulich wrote: On 22.12.16 at 09:12, wrote: Other than that the primary thing I'm missing (as I think I've mentioned elsewhere already) is a rationale

[Xen-devel] [PATCH] xen: Fix build with older versions of GCC following e34bc403c3

GCCs of at least 4.4 and earlier do not tollerate the initialisiation of the $VENDOR_cpu_dev structures, because of c_ident becoming an anonymous union. Instead of using an anonymous union, reintepret c_ident[] in its CPUID form just in get_cpu_vendor(). Signed-off-by: Andrew Cooper

Re: [Xen-devel] [RFC PATCH v2 03/26] ARM: GICv3 ITS: allocate device and collection table

Hi Stefano, On 04/01/17 21:47, Stefano Stabellini wrote: > On Thu, 22 Dec 2016, Andre Przywara wrote: >> Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and >> an EventID (the MSI payload or interrupt ID) to a pair of LPI number >> and collection ID, which points to the target

Re: [Xen-devel] [RFC PATCH v2 02/26] ARM: GICv3: allocate LPI pending and property table

On Thu, 5 Jan 2017, Andre Przywara wrote: > Hi, > > On 04/01/17 21:09, Stefano Stabellini wrote: > > On Thu, 22 Dec 2016, Andre Przywara wrote: > >> The ARM GICv3 ITS provides a new kind of interrupt called LPIs. > >> The pending bits and the configuration data (priority, enable bits) for > >>

Re: [Xen-devel] Xenstore/ xenstored

On Thu, Jan 05, 2017 at 04:57:27PM +0100, Yessine Daoud wrote: > Hello, > > I have a question regarding the daemon xenstored running on dom0. > Xenstored is responsable for communication with xenstore. > > How xenstored dump the xenstore? for example I send the following path to > xenstored : >

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

On 05/01/17 17:17, Doug Goldstein wrote: > On 1/5/17 11:08 AM, Jan Beulich wrote: > On 05.01.17 at 17:26, wrote: >>> -static void set_fixed_range(int msr, int * changed, unsigned int * >>> msrwords) >>> +static void set_fixed_range(int msr, bool * changed, unsigned int *

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

On 1/5/17 11:08 AM, Jan Beulich wrote: On 05.01.17 at 17:26, wrote: >> -static void set_fixed_range(int msr, int * changed, unsigned int * msrwords) >> +static void set_fixed_range(int msr, bool * changed, unsigned int * >> msrwords) > > Would have been nice to get the

Re: [Xen-devel] [RFC PATCH v2 02/26] ARM: GICv3: allocate LPI pending and property table

Hi, On 04/01/17 21:09, Stefano Stabellini wrote: > On Thu, 22 Dec 2016, Andre Przywara wrote: >> The ARM GICv3 ITS provides a new kind of interrupt called LPIs. >> The pending bits and the configuration data (priority, enable bits) for >> those LPIs are stored in tables in normal memory, which

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

>>> On 05.01.17 at 17:26, wrote: > -static void set_fixed_range(int msr, int * changed, unsigned int * msrwords) > +static void set_fixed_range(int msr, bool * changed, unsigned int * msrwords) Would have been nice to get the stray blanks here and elsewhere dropped, as the

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

On 05/01/17 16:53, Boris Ostrovsky wrote: > On 01/04/2017 08:33 AM, Jan Beulich wrote: > On 03.01.17 at 13:06, wrote: >>> --- a/xen/arch/x86/cpu/cpu.h >>> +++ b/xen/arch/x86/cpu/cpu.h >>> @@ -1,9 +1,13 @@ >>> /* attempt to consolidate cpu attributes */ >>> struct

Re: [Xen-devel] [edk2] [PATCH RFC 14/14] XenOvmf: Use a different RTC

On 12/08/16 16:33, Anthony PERARD wrote: > --- > OvmfPkg/XenOvmf.dsc | 5 - > OvmfPkg/XenOvmf.fdf | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc > index a7a884e..345157b 100644 > --- a/OvmfPkg/XenOvmf.dsc > +++

Re: [Xen-devel] [edk2] [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

On 12/08/16 16:33, Anthony PERARD wrote: > This "device" use XenIoMmioLib to reserve some space to be use by grant > tables. It's use 0xfc00, which might not be a good choice... > > There is probably a better way that using a device for this. > --- > OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 263

Re: [Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

On 05/01/17 16:26, Doug Goldstein wrote: > Instead of using an int and providing a define for TRUE and FALSE, > change the code to use stdbool that Xen provides. > > Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper and queued

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

On 01/04/2017 08:33 AM, Jan Beulich wrote: On 03.01.17 at 13:06, wrote: >> --- a/xen/arch/x86/cpu/cpu.h >> +++ b/xen/arch/x86/cpu/cpu.h >> @@ -1,9 +1,13 @@ >> /* attempt to consolidate cpu attributes */ >> struct cpu_dev { >> -char* c_vendor; >> +char

Re: [Xen-devel] [edk2] [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

On 12/08/16 16:33, Anthony PERARD wrote: > and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform. > > It actually look for gEfiSerialIoProtocolGuid. > --- > .../Library/PlatformBootManagerLib/BdsPlatform.c | 33 > ++ > .../PlatformBootManagerLib.inf

[Xen-devel] [qemu-mainline test] 104044: tolerable FAIL - PUSHED

flight 104044 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104044/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 103992 test-armhf-armhf-xl-rtds

Re: [Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3

Wei Liu writes ("Re: [PATCH v2 2/2] build: use debug_symbols to add -g3"): > On Tue, Jan 03, 2017 at 02:07:31AM -0700, Jan Beulich wrote: > > On 23.12.16 at 13:24, wrote: > > > @@ -146,7 +146,7 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan) > > >

[Xen-devel] [PATCH] x86/mtrr: use stdbool instead of int + define

Instead of using an int and providing a define for TRUE and FALSE, change the code to use stdbool that Xen provides. Signed-off-by: Doug Goldstein --- xen/arch/x86/cpu/mtrr/generic.c | 21 +++-- xen/arch/x86/cpu/mtrr/mtrr.h| 5 - 2 files changed, 11

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

Wei Liu writes ("[PATCH v2] build: move setting LTO options to xen/Rules.mk"): > Having them in StdGNU.mk would affect both hypervisor and tools build. > However judging from the commit message of e4cdd74f LTO was only meant > to affect hypvervisor build. > > Move the relevant bits to

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

>>> On 05.01.17 at 17:03, wrote: > On 01/05/2017 05:45 PM, Jan Beulich wrote: > On 22.12.16 at 09:12, wrote: >> Other than that the primary thing I'm missing (as I think I've >> mentioned elsewhere already) is a rationale of why this new >> protocol is

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

>>> On 31.12.16 at 06:46, wrote: > +void __init setup_avic_dump(void) > +{ > +register_keyhandler('j', avic_dump, "dump SVM AVIC", 1); > +} For one the description should include the word "stats". And then I'm rather uncertain this is work burning one of the

Re: [Xen-devel] [PATCH v2 09/10] x86/SVM: Hook up miscellaneous AVIC functions

>>> On 31.12.16 at 06:46, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1438,6 +1438,11 @@ static int svm_cpu_up(void) > return 0; > } > > +static inline int svm_avic_enabled(void) bool? > @@ -1472,16 +1477,27 @@ const

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

On 01/05/2017 05:45 PM, Jan Beulich wrote: On 22.12.16 at 09:12, wrote: +struct xendispl_pg_flip_evt { +uint64_t fb_cookie; Considering that apparently all operations have this cookie, I think it would better go ... +}; + +struct xendispl_req { +uint16_t id; +

Re: [Xen-devel] [PATCH v2 08/10] x86/SVM: Add interrupt management code via AVIC

>>> On 31.12.16 at 06:45, wrote: > --- a/xen/arch/x86/hvm/svm/avic.c > +++ b/xen/arch/x86/hvm/svm/avic.c > @@ -636,6 +636,34 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs > *regs) > return; > } > > +void svm_avic_deliver_posted_intr(struct vcpu

[Xen-devel] Request for help: Help integrating Xen into Google oss-fuzz

Hi all Oss-fuzz [0] is a continuous fuzzing service for open source software. During last release cycle we put in a lot of effort to fuzz Xen, so it would make sense to try to run it in oss-fuzz. We've already committed two fuzzing targets (x86 emulator and libelf, both of which happen to get a

[Xen-devel] Xenstore/ xenstored

Hello, I have a question regarding the daemon xenstored running on dom0. Xenstored is responsable for communication with xenstore. How xenstored dump the xenstore? for example I send the following path to xenstored : /local/domain/1/name: normally xenstored will receive this path and will search

Re: [Xen-devel] [PATCH v2 03/10] x86/HVM: Call vlapic_destroy after vcpu_destroy

>>> On 31.12.16 at 06:45, wrote: > Since vlapic_init() is called before vcpu_initialise(). > We should call the destroy functions in the the reverse order here. Double "the". And to quote from my RFC reply: "Also the ordering issue extends to other calls, and I

Re: [Xen-devel] [PATCH v2 02/10] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static

>>> On 31.12.16 at 06:45, wrote: > Expose vlapic_read_aligned and vlapic_reg_write() to be used by AVIC. > > Signed-off-by: Suravee Suthikulpanit > Reviewed-by: Konrad Rzeszutek Wilk Generally I dislike

Re: [Xen-devel] [PATCH v2 01/10] x86/HVM: Introduce struct hvm_pi_ops

>>> On 31.12.16 at 06:45, wrote: > --- a/xen/include/asm-x86/hvm/domain.h > +++ b/xen/include/asm-x86/hvm/domain.h > @@ -72,6 +72,67 @@ struct hvm_ioreq_server { > bool_t bufioreq_atomic; > }; > > +struct hvm_pi_ops { > +/* > + * To

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

>>> On 22.12.16 at 09:12, wrote: > +struct xendispl_pg_flip_evt { > +uint64_t fb_cookie; Considering that apparently all operations have this cookie, I think it would better go ... > +}; > + > +struct xendispl_req { > +uint16_t id; > +uint8_t operation; > +

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

>>> On 05.01.17 at 16:02, wrote: > On 05/01/17 14:52, Jan Beulich wrote: > On 05.01.17 at 15:28, wrote: >>> What else would you suggest? One way or another (better shown in the >>> context of the following patch), we need one block per

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

>>> On 05.01.17 at 16:23, wrote: > On 05/01/17 15:09, Wei Liu wrote: >> On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote: >>> Having them in StdGNU.mk would affect both hypervisor and tools build. >>> However judging from the commit message of e4cdd74f LTO was

[Xen-devel] [xen-unstable test] 104040: tolerable FAIL

flight 104040 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104040/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104034

Re: [Xen-devel] [PATCH v2] x86: drop cpu_has_sse{,2}

On 05/01/17 15:12, Jan Beulich wrote: > Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly > added them - these features are always available on 64-bit CPUs. (Let's > not assume this for MMX though in at least the insn emulator.) > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

On Thu, Jan 05, 2017 at 04:12:46PM +0100, Cedric Bosdonnat wrote: > On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote: > > On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote: > > > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote: > > > > On Fri, Dec 09, 2016 at 05:17:03PM +0100,

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

On 05/01/17 15:09, Wei Liu wrote: > On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote: >> Having them in StdGNU.mk would affect both hypervisor and tools build. >> However judging from the commit message of e4cdd74f LTO was only meant >> to affect hypvervisor build. >> >> Move the relevant

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

>>> On 05.01.17 at 16:09, wrote: > On 12/22/16 8:46 AM, Jan Beulich wrote: > On 07.12.16 at 16:57, wrote: >>> efi/buildid.o: file not recognized: File format is ambiguous >>> efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 >> >> Just

Re: [Xen-devel] [PATCH v2] build: move setting LTO options to xen/Rules.mk

On Fri, Dec 23, 2016 at 12:12:36PM +, Wei Liu wrote: > Having them in StdGNU.mk would affect both hypervisor and tools build. > However judging from the commit message of e4cdd74f LTO was only meant > to affect hypvervisor build. > > Move the relevant bits to xen/Rules.mk. > > Signed-off-by:

Re: [Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3

On Tue, Jan 03, 2017 at 02:07:31AM -0700, Jan Beulich wrote: > >>> On 23.12.16 at 13:24, wrote: > > @@ -146,7 +146,7 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan) > > -Wl,-rpath-link=$(XEN_LIBVCHAN) > > > > ifeq ($(debug),y) > > # Disable optimizations and enable

Re: [Xen-devel] [PATCH 27/27] x86/cpuid: Alter the legacy-path prototypes to match guest_cpuid()

On 05/01/17 14:19, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> Here and elsewhere, it is becomes very obvious that the PVH path using >> pv_cpuid() is broken, as the guest_kernel_mode() check using >> guest_cpu_user_regs() is erroneous. I am tempted to just

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

On Thu, 2017-01-05 at 15:01 +, Wei Liu wrote: > On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote: > > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote: > > > On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote: > > > > As pointed out in Ian and Andrew's emails on

[Xen-devel] [PATCH v2] x86: drop cpu_has_sse{,2}

Commit dc88221c97 ("x86: rename XMM* features to SSE*") pointlessly added them - these features are always available on 64-bit CPUs. (Let's not assume this for MMX though in at least the insn emulator.) Signed-off-by: Jan Beulich --- v2: Add a test harness comment clarifying

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

On 12/22/16 8:46 AM, Jan Beulich wrote: On 07.12.16 at 16:57, wrote: >> efi/buildid.o: file not recognized: File format is ambiguous >> efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 > > Just fyi: After some analysis of the binutils sources I have come

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

On 05/01/17 14:52, Jan Beulich wrote: On 05.01.17 at 15:28, wrote: >> On 05/01/17 13:51, Jan Beulich wrote: @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int leaf, unsigned int subleaf, struct cpuid_leaf

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

On Wed, Jan 04, 2017 at 04:49:25PM +0100, Cedric Bosdonnat wrote: > On Wed, 2017-01-04 at 15:07 +, Wei Liu wrote: > > On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote: > > > As pointed out in Ian and Andrew's emails on my recent docs improvement > > > attempt, getting the

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

>>> On 05.01.17 at 15:28, wrote: > On 05/01/17 13:51, Jan Beulich wrote: >>> @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int >>> leaf, >>> unsigned int subleaf, struct cpuid_leaf *res) >>> { >>> const struct domain *d =

Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

>>> On 05.01.17 at 15:53, wrote: > On 05/01/17 08:27, Jan Beulich wrote: > On 04.01.17 at 18:21, wrote: >>> On 04/01/17 15:44, Jan Beulich wrote: >>> On 04.01.17 at 13:39, wrote: > Use anonymous unions

Re: [Xen-devel] [PATCH 11/27] x86/hvm: Improve hvm_efer_valid() using named features

On 05/01/17 11:34, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -914,56 +914,35 @@ static int hvm_save_cpu_ctxt(struct domain *d, >> hvm_domain_context_t *h) >> } >> >> /* Return a string

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

>>> On 05.01.17 at 15:42, wrote: > On 05/01/17 08:24, Jan Beulich wrote: > On 04.01.17 at 18:37, wrote: >>> On 04/01/17 16:04, Jan Beulich wrote: >>> On 04.01.17 at 16:33, wrote: > On 04/01/17 15:01,

Re: [Xen-devel] [PATCH 23/27] x86/cpuid: Move all leaf 7 handling into guest_cpuid()

>>> On 05.01.17 at 15:39, wrote: > On 05/01/17 14:01, Jan Beulich wrote: > On 04.01.17 at 13:39, wrote: >>> @@ -380,14 +385,42 @@ void guest_cpuid(const struct vcpu *v, unsigned int > leaf, >>> case 0x8000 ... 0x8000 +

Re: [Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

On 05/01/17 08:27, Jan Beulich wrote: On 04.01.17 at 18:21, wrote: >> On 04/01/17 15:44, Jan Beulich wrote: >> On 04.01.17 at 13:39, wrote: Use anonymous unions to access the feature leaves as complete words, and by named

Re: [Xen-devel] Ping: [PATCH v2 RESEND] x86/time: correctly honor late clearing of TSC related feature flags

>>> On 20.12.16 at 13:35, wrote: > Once we have ever had cause to use time_calibration_tsc_rendezvous, > there is no situation where it is safe to switch back to > time_calibration_std_rendezvous, as the choice to use > time_calibration_tsc_rendezvous means the TSCs

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

flight 104046 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104046/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

On 05/01/17 08:24, Jan Beulich wrote: On 04.01.17 at 18:37, wrote: >> On 04/01/17 16:04, Jan Beulich wrote: >> On 04.01.17 at 16:33, wrote: On 04/01/17 15:01, Jan Beulich wrote: On 04.01.17 at 13:39,

Re: [Xen-devel] [PATCH 23/27] x86/cpuid: Move all leaf 7 handling into guest_cpuid()

On 05/01/17 14:01, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> @@ -380,14 +385,42 @@ void guest_cpuid(const struct vcpu *v, unsigned int >> leaf, >> case 0x8000 ... 0x8000 + CPUID_GUEST_NR_EXTD - 1: >> if ( leaf > p->extd.max_leaf ) >>

Re: [Xen-devel] [PATCH 21/27] x86/cpuid: Calculate appropriate max_leaf values for the global policies

>>> On 05.01.17 at 15:13, wrote: > On 05/01/17 13:43, Jan Beulich wrote: > On 04.01.17 at 13:39, wrote: >>> --- a/xen/include/asm-x86/cpuid.h >>> +++ b/xen/include/asm-x86/cpuid.h >>> @@ -78,10 +78,10 @@ struct cpuid_policy >>> *

Re: [Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

On 05/01/17 13:51, Jan Beulich wrote: > >> @@ -333,21 +340,50 @@ void guest_cpuid(const struct vcpu *v, unsigned int >> leaf, >> unsigned int subleaf, struct cpuid_leaf *res) >> { >> const struct domain *d = v->domain; >> +const struct cpuid_policy *p = d->arch.cpuid;

Re: [Xen-devel] [PATCH 27/27] x86/cpuid: Alter the legacy-path prototypes to match guest_cpuid()

>>> On 04.01.17 at 13:39, wrote: > Here and elsewhere, it is becomes very obvious that the PVH path using > pv_cpuid() is broken, as the guest_kernel_mode() check using > guest_cpu_user_regs() is erroneous. I am tempted to just switch PVH onto the > HVM path, which

Re: [Xen-devel] [PATCH] x86/head: Refactor 32-bit pgtable setup

On 01/05/2017 03:52 AM, Ingo Molnar wrote: > > Yeah, so (belatedly) I tried to merge this to latest upstream, via the commit > below (note the slight edits to the changelog) - but 32-bit defconfig fails > to > build: > > arch/x86/kernel/head_32.S:615: Error: can't resolve `init_thread_union'

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

Hi Shaohua, Thanks for your reply. Let me explain my "huge". For example, if I'm making a low rate i/o stream, I don't get a crash (<1MB written / sec) with random i/o, but if I'm making a random I/O of about 20MB/sec, the kernel crashes in a few minutes (for example, making an rsync, or

Re: [Xen-devel] [PATCH 21/27] x86/cpuid: Calculate appropriate max_leaf values for the global policies

On 05/01/17 13:43, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> --- a/xen/include/asm-x86/cpuid.h >> +++ b/xen/include/asm-x86/cpuid.h >> @@ -78,10 +78,10 @@ struct cpuid_policy >> * Global *_policy objects: >> * >> * - Host accurate: >> -

Re: [Xen-devel] [PATCH 26/27] x86/cpuid: Effectively remove pv_cpuid() and hvm_cpuid()

On 05/01/17 14:06, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy >> path) have been removed from the codebase. Move them into cpuid.c to avoid >> any further use, leaving guest_cpuid()

Re: [Xen-devel] [PATCH 26/27] x86/cpuid: Effectively remove pv_cpuid() and hvm_cpuid()

>>> On 04.01.17 at 13:39, wrote: > All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy > path) have been removed from the codebase. Move them into cpuid.c to avoid > any further use, leaving guest_cpuid() as the sole API to use. > >

  1   2   >