Hi Boris/Andrew,
On 1/3/17 23:04, Andrew Cooper wrote:
On 03/01/17 16:01, Boris Ostrovsky wrote:
+static void avic_dump(unsigned char ch)
+{
+struct domain *d;
+struct vcpu *v;
+
+printk("*** SVM AVIC Statistics **\n");
+
+rcu_read_lock(&domlist_read_lock);
>>> 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. */
> +if ( !d->disable_migrate && !d->arch.vtsc )
>>> 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 introduced for every architectural X86_FEATURE_*, oth
flight 104034 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104034/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104030
test-amd64-i386-xl-qemuu-wi
- small fixes for xenbus driver
- one fix for xen dom0 boot on huge system
- small cleanups
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.10-rc2-tag
xen: features and fixes for 4.10 rc2
- small fixes for xenbus driver
- one fi
On Thu, 2017-01-05 at 02:05 +, Andrew Cooper wrote:
> On 05/01/2017 01:52, Konrad Rzeszutek Wilk wrote:
> > It works just fine with credit1 (see further down the log)
> > but if I try credit2 it ends up hanging during bootup.
> >
> > I am a going to naively assume it is due to how the vCPUs a
flight 104038 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104038/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 74e2b93496778d3242fdb76d2f741365d79222a0
baseline version:
ovmf b3724a03d6df2aa5c51c9
* Boris Ostrovsky wrote:
> The new Xen PVH entry point requires page tables to be setup by the
> kernel since it is entered with paging disabled.
>
> Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
> invoked from both the new Xen entry point and the existing startup_32
>
>>> 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 *ctxt,
>> + const struct
On 05/01/2017 08:39, Dario Faggioli wrote:
> On Thu, 2017-01-05 at 02:05 +, Andrew Cooper wrote:
>> On 05/01/2017 01:52, Konrad Rzeszutek Wilk wrote:
>>> It works just fine with credit1 (see further down the log)
>>> but if I try credit2 it ends up hanging during bootup.
>>>
>>> I am a going to
This run is configured for baseline tests only.
flight 68319 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68319/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop
On 12/08/16 16:33, Anthony PERARD wrote:
> A copy of OvmfPkg/PlatformPei without some of QEMU specific
> initialization, Xen does not support QemuFwCfg.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/XenOvmf.dsc |
Signed-off-by: Roger Pau Monné
Reported-by: Fatih Acar
---
Cc: Ian Jackson
Cc: Wei Liu
---
This should be backported to all supported stable branches (4.6, 4.7, 4.8).
---
Changes since v1:
- Move fetching the scheduler parameters before device configuration.
- Call libxl_domain_sched_params_d
On 12/08/16 16:33, Anthony PERARD wrote:
> A copy of OvmfPkg/Library/PciHostBridgeLib
>
> Removing support for pci bus enumeration, I think, and only use scan of
> already enumerated pci bus.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
> ...
On 12/08/16 16:33, Anthony PERARD wrote:
> - learn about memory size from the E820
> - ignore error if host bridge devid is 0x, PVH does not have PCI and
> reading from unexisting device return -1.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
>
On 12/08/16 16:33, Anthony PERARD wrote:
> This one enter directly in 32bits
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 79
> +
> OvmfPkg/XenResetVector/Ia32/XenPVH
On 12/08/16 16:33, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPla
On Wed, Jan 04, 2017 at 11:45:15AM +, Roger Pau Monne wrote:
> On Wed, Jan 04, 2017 at 11:35:54AM +, Wei Liu wrote:
> > On Wed, Jan 04, 2017 at 11:20:41AM +, Roger Pau Monne wrote:
> > > On Wed, Jan 04, 2017 at 11:08:51AM +, Wei Liu wrote:
> > > > On Wed, Jan 04, 2017 at 09:55:59AM
On 12/08/16 16:33, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
Eliminate the mis-naming of 64-bit fields with 32-bit register names
(eflags instead of rflags etc). To ensure no piece of code was missed,
transiently use the underscore prefixed names only for 32-bit register
accesses. This will be cleaned up subsequently.
Signed-off-by: Jan Beulich
---
This is
On Thu, Jan 05, 2017 at 10:08:34AM +, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> Reported-by: Fatih Acar
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Most invocations of the instruction emulator are for VM exits where the
set of legitimate instructions (i.e. ones capable of causing the
respective exit) is rather small. Restrict the permitted sets via a new
callback, at once eliminating the abuse of handle_mmio() for non-MMIO
operations.
A seemi
On 12/08/16 16:33, Anthony PERARD wrote:
> And replacing the ACPI Timer by this one based on the local APIC.
>
> ACPI Timer does not work in a PVH guest, but local APIC works on both
> PVH and HVM.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD
> ---
>>> 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 NULL for valid. */
> -const char *hvm_efer_valid
>>> On 04.01.17 at 13:39, wrote:
> Alter the function to return the valid CR4 bits, rather than the invalid CR4
> bits. This will allow reuse in other areas of code.
>
> Pick the appropriate cpuid_policy object rather than using hvm_cpuid() or
> boot_cpu_data. This breaks the dependency on curr
On Wed, Jan 04, 2017 at 12:43:02PM +, George Dunlap wrote:
> On Wed, Jan 4, 2017 at 12:36 PM, George Dunlap
> wrote:
> > 4. The security team will only issue an advisory if there is a known
> > combination of software in which the vulnerability can be exploited.
> >
> > In most cases, the sof
>>> On 04.01.17 at 13:39, wrote:
> Reuse the logic in hvm_cr4_guest_valid_bits() instead of duplicating it.
>
> This fixes a bug to do with the handling of X86_CR4_PCE. The RDPMC
> instruction predate the architectural performance feature, and has been around
> since the P6. X86_CR4_PCE is like
On Thu, Jan 05, 2017 at 03:50:50AM -0700, Jan Beulich wrote:
> Eliminate the mis-naming of 64-bit fields with 32-bit register names
> (eflags instead of rflags etc). To ensure no piece of code was missed,
> transiently use the underscore prefixed names only for 32-bit register
> accesses. This will
>>> On 04.01.17 at 13:39, wrote:
> This avoids refering back to domain_cpuid() or native CPUID to obtain
> information which is directly available.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists
On Fri, Dec 16, 2016 at 05:52:29AM -0700, Jan Beulich wrote:
> Hello,
>
> especially some of the changes late in the 4.8 cycle have caused me
> to spend a good part of the morning trying to figure out how to build
> the tool stack on an older system. Among other things I've run into
> - ipxe all o
On Wed, Jan 4, 2017 at 6:00 PM, Austin S. Hemmelgarn
wrote:
> On 2017-01-04 09:50, Jan Marquardt wrote:
>>
>> Hi,
>>
>> unfortunately we still have a lot of paravirtual guests with 32 Bit OS
>> and are currently running in some problems.
>>
>> As far as I understand the documentation in xend-confi
On Wed, Jan 04, 2017 at 11:40:21AM -0800, 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 granted/revoked for each packet being
>>> On 05.01.17 at 12:47, wrote:
> On Fri, Dec 16, 2016 at 05:52:29AM -0700, Jan Beulich wrote:
>> Hello,
>>
>> especially some of the changes late in the 4.8 cycle have caused me
>> to spend a good part of the morning trying to figure out how to build
>> the tool stack on an older system. Among
On Fri, Dec 09, 2016 at 05:17:05PM +0100, Cédric Bosdonnat wrote:
> Some of the docs/misc documents will need to go in man 7 section,
> prepare docs/Makefile for it.
>
> Signed-off-by: Cédric Bosdonnat
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen
ctxt->addr_size is expressed in bits rather than bytes, and has the value 16,
32 or 64. Comparing < 8 made the intended non-64bit paths dead.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/ar
The I/O bitmap doesn't change function depending on mode. 64bit userspace
such as an X server still needs to enter guest_io_okay() to find that the PV
kernel did set up an appropriate virtual I/O bitmap to permit access.
While moving the check, alter its representation to be easier to read.
Sign
(dropping xen.users, to avoid cross posting)
>>> On 05.01.17 at 12:47, wrote:
> On Wed, Jan 4, 2017 at 6:00 PM, Austin S. Hemmelgarn
> wrote:
>> On 2017-01-04 09:50, Jan Marquardt wrote:
>>> unfortunately we still have a lot of paravirtual guests with 32 Bit OS
>>> and are currently running in s
On Thu, Jan 05, 2017 at 04:57:12AM -0700, Jan Beulich wrote:
> >>> On 05.01.17 at 12:47, wrote:
> > On Fri, Dec 16, 2016 at 05:52:29AM -0700, Jan Beulich wrote:
> >> Hello,
> >>
> >> especially some of the changes late in the 4.8 cycle have caused me
> >> to spend a good part of the morning tryin
>>> On 04.01.17 at 13:39, wrote:
> This avoids hvm_cpuid() recursing into itself, and the MSR paths using
> hvm_cpuid() to obtain information which is directly available.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel maili
>>> On 05.01.17 at 13:00, wrote:
> ctxt->addr_size is expressed in bits rather than bytes, and has the value 16,
> 32 or 64. Comparing < 8 made the intended non-64bit paths dead.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Tested-by: Jan Beulich
__
>>> On 05.01.17 at 13:00, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2169,6 +2169,19 @@ static int priv_op_read_segment(enum x86_segment seg,
> struct segment_register *reg,
> struct x86_emulate_ctxt *ctx
>>> On 05.01.17 at 13:04, wrote:
> On Thu, Jan 05, 2017 at 04:57:12AM -0700, Jan Beulich wrote:
>> >>> On 05.01.17 at 12:47, wrote:
>> > If I'm not mistaken this requires we track tool chain requirements for
>> > all dependencies and their dependencies. This is going to be
>> > unmanageable.
>>
On 05/01/17 12:15, Jan Beulich wrote:
On 05.01.17 at 13:00, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -2169,6 +2169,19 @@ static int priv_op_read_segment(enum x86_segment seg,
>> struct segment_register *reg,
>>
>>> On 04.01.17 at 13:39, wrote:
> ... rather than dynamically claming against the PV maximum policy.
What is "claming"? I'm even having a hard time guessing what you
may have meant - clamping maybe?
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
On 05/01/17 12:23, Jan Beulich wrote:
On 04.01.17 at 13:39, wrote:
>> ... rather than dynamically claming against the PV maximum policy.
> What is "claming"? I'm even having a hard time guessing what you
> may have meant - clamping maybe?
Yes. I did mean clamping and had already fixed this
flight 68322 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68322/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68288
jobs:
build-amd64 pass
build-armh
This run is configured for baseline tests only.
flight 68321 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68321/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6e0e994d0e855f7f65f6fb7e113f061e0b9a242
baseline v
>>> On 04.01.17 at 13:39, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1065,11 +1065,8 @@ void pv_cpuid(struct cpu_user_regs *regs)
> uint32_t tmp;
>
> case 0x0001:
> -c &= pv_featureset[FEATURESET_1c];
> -d &= pv_featureset[FEATURESET_
On 05/01/17 12:44, Jan Beulich wrote:
On 04.01.17 at 13:39, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1065,11 +1065,8 @@ void pv_cpuid(struct cpu_user_regs *regs)
>> uint32_t tmp;
>>
>> case 0x0001:
>> -c &= pv_featureset[FEATURESET_
flight 104042 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104042/
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 04.01.17 at 13:39, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3335,39 +3335,33 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> *ebx &= 0x00FFu;
> *ebx |= (v->vcpu_id * 2) << 24;
>
> -*ecx &= hvm
On 05/01/17 12:55, 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
>> @@ -3335,39 +3335,33 @@ void hvm_cpuid(unsigned int input, unsigned int
>> *eax, unsigned int *ebx,
>> *ebx &= 0x00FFu;
>> *ebx |= (v->v
>>> On 04.01.17 at 13:39, wrote:
> static void __init calculate_pv_max_policy(void)
> {
> struct cpuid_policy *p = &pv_max_policy;
> +uint32_t pv_featureset[FSCAPINTS], host_featureset[FSCAPINTS];
> unsigned int i;
>
> +cpuid_policy_to_featureset(&host_policy, host_featureset
On 05/01/17 13:07, Jan Beulich wrote:
On 04.01.17 at 13:39, wrote:
>> static void __init calculate_pv_max_policy(void)
>> {
>> struct cpuid_policy *p = &pv_max_policy;
>> +uint32_t pv_featureset[FSCAPINTS], host_featureset[FSCAPINTS];
>> unsigned int i;
>>
>> +cpuid_poli
>>> 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
> * - {xcr0,xss}_{high,low}
> *
>
>>> On 04.01.17 at 13:39, wrote:
> @@ -306,6 +310,9 @@ void recalculate_cpuid_policy(struct domain *d)
> if ( !d->disable_migrate && !d->arch.vtsc )
> __clear_bit(X86_FEATURE_ITSC, fs);
>
> +if ( p->basic.max_leaf < 0xd )
XSTATE_CPUID
> @@ -333,21 +340,50 @@ void guest_cpuid(
>>> 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;
> -break;
> +goto legacy;
>
>
>>> On 04.01.17 at 13:39, wrote:
> More work is required before maxphysaddr can be read straight out of the
> cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so
> update the code to use the newer interface.
>
> Use the behaviour of max_leaf handling (returning all zeros) to
>>> On 04.01.17 at 13:39, wrote:
> More work is required before LWP details can be read straight out of the
> cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so
> update the code to use the newer interface.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit
>>> 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
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 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
>>
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 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'
>>> 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 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 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 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 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. */
>> +
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 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
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 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 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 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: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 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 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 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 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
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 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
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 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 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 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 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 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: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
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 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
>>> 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 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 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 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:
> 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
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
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
>>> 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
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;
+
1 - 100 of 159 matches
Mail list logo
