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 42b85551615d62fb68f0d
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 74e2b93496778d3242fdb
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. com1=
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. com1=
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. com1=
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 debian-di-inst
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
test-armhf-armhf-libvirt-x
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 a
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 reusa
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
test-amd64-i386-xl-qemut-wi
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
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_ L
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 1
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 parameter
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 thr
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 sav
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 to
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
> GI
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 vuln
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 injec
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 wo
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 v
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
>
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 gr
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, Stefano
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
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 parameter
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 get_cpu
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 co
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, t
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.
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:
> > > >
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): /* Grp15
> */
> s
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 clear_bnd(struct x86_emulate_ctxt
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, as
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 a/xen/include/asm-x86/hvm/vmx/vmx.h
b/xen/include/asm
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 1
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 of why this new
protocol is needed (and t
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
---
CC: Jan
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 C
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
> >> tho
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 :
> /
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 *
>>> msrwords)
>> Wou
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 stray blanks here and
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 sof
>>> 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 lines are being touched
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 cpu_dev {
>>> - char*
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
> +++ b/OvmfPkg/X
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
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
___
Xen-devel mai
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;
>> +charc_vendor[8];
>>
>> -
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
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
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)
> > > -Wl,-rpath-link=$(XEN_LIBVCHAN)
> > >
> > > ifeq
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 insertions(+), 15 del
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 xen/Rules.mk
>>> 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 needed (and the existing xenfb one can't
>>> 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 few remaining
available keys. Coul
>>> 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 struct hvm_function_table * __in
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;
+uint8_t operation;
+
>>> 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 *v, u8 vec)
> +{
> +struct vla
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 l
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
>>> 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 think if at all
possible we shoul
>>> 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 functions being non-static when all their callers
live in the same file. Therefore it would
>>> 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 handle posted interrupts correctl
>>> 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;
> +uint8_t reserved[5];
.
>>> 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 union{} to apply
>>> max_leaf calculations and read the
>>> 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 only meant
>>> to affect hypve
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
test-amd64-i386-xl-qemut-wi
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
Reviewed-by: Andrew
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, Cédri
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 bi
>>> 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 fyi: After some analysis of the binutils
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:
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 debugging information for mac
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 switch PVH onto the
>> HVM
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 my
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 host_and_vcpu_must_ha
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 to
> the conclusion t
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 *res)
{
const s
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 docume
>>> 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 = v->domain;
>>> +const s
>>> 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 to access the feature leaves as complete words, and
> by
> named individu
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 indicating the error, or NU
>>> 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, Jan Beulich wrote:
> On 04.01.17 at 13:39, wrote:
>>> static void upda
>>> 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 + CPUID_GUEST_NR_EXTD - 1:
>>> if ( leaf > p->extd.ma
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 individual feature.
A feature name is introduc
>>> 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 aren't in sync, and Xen
> has n
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 1
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, wrote:
>> +/* ... but hide ITSC in the common case. */
>> +
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 )
>> return;
>> -
>>> 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
>>> * Global *_policy objects:
>>> *
>>> * - Host a
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;
>
>>> 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 won't make it any more broken t
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'
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 even
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:
>> - * - max_{,sub}leaf
>>
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() as the sole API to use.
>>
>>> 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.
>
> Signed-off-by: Andrew Cooper
Assuming
1 - 100 of 159 matches
Mail list logo
