On Sun, Oct 18, 2015 at 8:26 PM, Gohar Irfan wrote:
> Where does Xen maintain the page table for each VM? The mapping of page
> number to frame numbers, basically.
Every domain has a structure called a "p2m table"
(physical-to-machine). For HVM guests, this is kept only in the
hypervisor; for PV
Hi there, it's my first question on Xen-devel email list.
I am glad to join here.
Could anybody guide me to some pointers on interrupt delivery procedure for
PV?
I tried to understand the way Xen delivers the interrupt by using xentrace.
I followed *do_IRQ* function but I am lost.
I want to know
On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote:
> George, Dario,
>
> it being mostly used in scheduler code, and me considering it quite a
> bit easier to compare such big numbers when shown in hex I wonder:
> Do you prefer this to stay PRId64, or would you accept it to be
> changed to PRIx64
From: Shuai Ruan
Changes in v7:
* Address comments form Jan,Andrew:
* Move macro XSTATE_FIXUP into patch3.
* Change lazy write to xss_msr in patch1.
* Drop inner set of brackets and stray cast in patch2.
* Move the condition and memcpy() wouldn't into the new called functions in
patch2.
* Rebase
This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.
Signed-off-by: Shuai Ruan
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 27 +++
xen/arch/x86/hvm/vmx/vmcs.c| 5 +
This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.
For xsaves/xrstors/xsavec only use compact format. Add format conversion
support when perform guest os migration.
Also, pv guest will not s
From: Shuai Ruan
This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
The reserved bits of eax/ebx/ecx/edx must be cleaned up
when call cpuid(0dh) with leaf 1 or 2..63.
According to the spec the following bits must be reserved:
For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved.
On 10/20/2015 10:10 AM, George Dunlap wrote:
On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote:
George, Dario,
it being mostly used in scheduler code, and me considering it quite a
bit easier to compare such big numbers when shown in hex I wonder:
Do you prefer this to stay PRId64, or would y
This patch add basic definitions/helpers which will be used in
later patches.
Signed-off-by: Shuai Ruan
Reviewed-by: Andrew Cooper
---
xen/arch/x86/xstate.c | 19 +++
xen/include/asm-x86/hvm/vcpu.h | 1 +
xen/include/asm-x86/msr-index.h | 2 ++
xen/include/asm-x86/x
>>> On 20.10.15 at 10:10, wrote:
> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote:
>> George, Dario,
>>
>> it being mostly used in scheduler code, and me considering it quite a
>> bit easier to compare such big numbers when shown in hex I wonder:
>> Do you prefer this to stay PRId64, or would
Many thanks for the attention, and the help so far!
* There are still warnings about the console not being properly configured.
This issue seems not urgent to me, also I would appreciate a fix.
* Something goes wrong while booting Dom0. Please help me in understanding why?
* I still don't know
On Mon, 2015-10-19 at 17:14 +0100, Ian Jackson wrote:
> On Linux opening /dev/stderr produces a non-O_APPEND open-file, with
> its own file position pointer, even if stderr was opened O_APPEND.
>
> As a result the logfile from this step would be mangled. So use
> `tee -a'.
>
> Signed-off-by: Ian
On Mon, 2015-10-19 at 17:15 +0100, Ian Jackson wrote:
> This contains osstest-developer-oriented information about the
> bisector, and is not really pitched at osstest consumers. (It's also
> rather more of a sketch than a complete algorithm doc, and somewhat
> out of date.)
>
> Signed-off-by: Ia
On Mon, Oct 19, 2015 at 05:51:25PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH 4/4] README.bisection: New
> consumer-oriented document"):
> > On Mon, Oct 19, 2015 at 05:15:35PM +0100, Ian Jackson wrote:
> > > + | url used for fetching the bits
> > > + |
> > > +
Please don't top-post.
On Tue, Oct 20, 2015 at 10:58:56AM +0800, 高强 wrote:
> Hi,
>
> If you know, could you tell me the call relationship of command "xl save".
> Example, when I execute "xl save",which function will be called first,and
> then call which function? I mainly want to know which pytho
flight 63065 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63065/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 6 xen-boot fail REGR. vs. 63042
test-amd64-i386-xl-qem
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 October 2015 17:01
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v4 1/5] public/io/netif.h: document the reality of
> ne
On 20/10/15 09:34, Jan Beulich wrote:
On 20.10.15 at 10:10, wrote:
>> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote:
>>> George, Dario,
>>>
>>> it being mostly used in scheduler code, and me considering it quite a
>>> bit easier to compare such big numbers when shown in hex I wonder:
>>
>>> On 20.10.15 at 04:34, wrote:
> Existing PML implementation turns on EPT A/D bit unconditionally if PML is
> supported by hardware. This works but enabling of EPT A/D bit can be
> deferred
> until PML get enabled. There's no point in enabling the extra feature for
> every
> domain when we're
>>> On 19.10.15 at 21:24, wrote:
> This change adds two options to xentop:
> -T adds a tabulator (\t) character after each field, to allow
> easier and more robust parsing. This affects batch mode only.
> -I includes a column with the domain ID in the outp
>>> On 19.10.15 at 18:25, wrote:
> On 10/19/2015 06:16 AM, John Doe wrote:
[0.00] general protection fault: [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.9-6.pvops.qubes.x86_64 #1
[0.00] Hardware na
On 19/10/15 15:51, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 19/10/15 15:51, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
mm bits:
Acked-by: George Dunlap
>
> --- a/xen/arch/x86/hvm/stdvga.c
> +++ b/xen/arch/x86/hvm/stdvga.c
> @@ -552,8 +552,7 @@ void stdvga_init(struct domain *d)
> {
> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
CC'ing xen-devel and Anthony
On Tue, 20 Oct 2015, suresh knv wrote:
> Hi Stefano,
>
> I am starting xencommons after the boot explicitly and also xl list
> works fine it is showing as below.
>
> ubuntu@arm64:~$ sudo xl list
> NameID Mem VCPUs State Time(
>>> On 20.10.15 at 11:46, wrote:
> On 20/10/15 09:34, Jan Beulich wrote:
> On 20.10.15 at 10:10, wrote:
>>> On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote:
George, Dario,
it being mostly used in scheduler code, and me considering it quite a
bit easier to compare such
On 20/10/15 03:34, Kai Huang wrote:
> Existing PML implementation turns on EPT A/D bit unconditionally if PML is
> supported by hardware. This works but enabling of EPT A/D bit can be deferred
> until PML get enabled. There's no point in enabling the extra feature for
> every
> domain when we're n
On 20/10/15 03:34, Kai Huang wrote:
> According to Jan's comments, also fix the coding style of for_each_vcpu in
> existing PML functions.
>
> Signed-off-by: Kai Huang
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:
Hi,
On 20/10/2015 09:48, Ferger, Max wrote:
Many thanks for the attention, and the help so far!
* There are still warnings about the console not being properly configured.
This issue seems not urgent to me, also I would appreciate a fix.
* Something goes wrong while booting Dom0. Please help
On 19/10/15 16:22, Jan Beulich wrote:
> -static struct vmcs_struct *vmx_alloc_vmcs(void)
> +static paddr_t vmx_alloc_vmcs(void)
> {
> +struct page_info *pg;
> struct vmcs_struct *vmcs;
>
> -if ( (vmcs = alloc_xenheap_page()) == NULL )
> +if ( (pg = alloc_domheap_page(NULL, 0)) =
On Tue, 2015-10-20 at 02:34 -0600, Jan Beulich wrote:
> > > > On 20.10.15 at 10:10, wrote:
> > Personally I've never taken the time to familiarize myself with the
> > magnitude of hex numbers vs decimal numbers; so in the case of
> > time, I
> > could easily see that 1000 nanoseconds is about
Hi Ians,
I found xen.git has RELEASE-4.6.0 tag, while corresponding 4.6.0 tags of
qemu-xen
and qemu-upstream are not in their trees, but in their *-4.6-testing trees.
Any reason for such arrangement?
Best Regards,
Robert Ho
___
Xen-devel mailing lis
On Tue, Oct 20, 2015 at 10:54:35AM +0100, Stefano Stabellini wrote:
> On Tue, 20 Oct 2015, suresh knv wrote:
> > I am starting xencommons after the boot explicitly and also xl list
> > works fine it is showing as below.
> >
> > ubuntu@arm64:~$ sudo xl list
> > Name
On Mon, 19 Oct 2015, Boris Ostrovsky wrote:
> On 10/19/2015 12:55 PM, Stefano Stabellini wrote:
> > When offlining a cpu, instead of cpu_down, call device_offline, which
> > also takes care of updating the cpu.dev.offline field. This keeps the
> > sysfs file /sys/devices/system/cpu/cpuN/online, up
On Tue, Oct 20, 2015 at 10:24:29AM +, Hu, Robert wrote:
> Hi Ians,
>
> I found xen.git has RELEASE-4.6.0 tag, while corresponding 4.6.0 tags of
> qemu-xen
> and qemu-upstream are not in their trees, but in their *-4.6-testing trees.
> Any reason for such arrangement?
>
I don't know the rea
Triggered by Konrad's needs for xSplice, but having been on my todo
list for a very long time to help interpretation of stack traces, here's a
first set of changes allowing to tell apart identically named static
symbols. The main and general thing is to prefix them by file name.
Some remaining coll
On Mon, 2015-10-19 at 12:44 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Switch to merged qemu-xen{,
> -traditional}.git trees"):
> > We discussed on IRC with you and Stefano and are going to aim to push
> > this
> > in the w/c 19 October.
>
> We have decided under the cir
>>> On 20.10.15 at 12:12, wrote:
> On 19/10/15 16:22, Jan Beulich wrote:
>> -static struct vmcs_struct *vmx_alloc_vmcs(void)
>> +static paddr_t vmx_alloc_vmcs(void)
>> {
>> +struct page_info *pg;
>> struct vmcs_struct *vmcs;
>>
>> -if ( (vmcs = alloc_xenheap_page()) == NULL )
>> +
This requires adjustments to the tool generating the symbol table and
its as well as nm's invocation.
Note: Not warning about duplicate symbols in the EFI case for now, as
a binutils bug causes misnamed file name entries to appear in EFI
binaries' symbol tables when the file name is longer than 18
To make it possible to tell apart the static symbols therein, use their
object file names instead of their source ones.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -29,6 +29,8 @@
#include
#include
+/* Allow uniquely identifying static
... to eliminate the resulting duplicate symbols. This includes
dropping an odd per-CPU variable left from 32-bit days: Now that we
only care about 64-bit builds, converting the uint64_t needing
passing to a void pointer is no problem anymore.
Since the COMPAT handling section needs to be re-organ
... to tell them apart by their names even without further context.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -75,7 +75,7 @@ static void svm_inject_extint(struct vcp
vmcb->eventinj = event;
}
-static void enable_intr_window(struct v
It doesn't depend on GUEST_PAGING_LEVELS.
Signed-off-by: Jan Beulich
---
TBD: To ensure no dependency on GUEST_PAGING_LEVELS, would it perhaps
be better to move the function to a file compiled just once?
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -87,8 +87,11 @
None of its elements depends on GUEST_PAGING_LEVELS.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -32,29 +32,32 @@
/* Allow uniquely identifying static symbols in the 3 generated objects. */
asm(".file \"guest_walk_" __stringify(GUEST_PAGI
On 20/10/15 11:39, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
I have no idea if the runes are correct, but the idea sounds great:
Acked-by: George Dunlap
>
> ---
On 19/10/15 15:53, Jan Beulich wrote:
> Rather than dirtying a page when establishing a (permanent) mapping,
> dirty it when the page gets unmapped, or - if still mapped - on the
> final iteration of a save operation (or in other cases where the guest
> is paused or already shut down). (Transient m
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -76,8 +76,10 @@ typedef enum {
ft_demand_write = FETCH_TYPE_DEMAND | FETCH_TYPE_WRITE,
} fetch_type_t;
-#ifdef DEBUG_TRACE_DUMP
-static char *fetch_type_names[] = {
+extern const char *
Instead of the misleading _guest_ ones use _sh_,
expressing their sole dependency on the number of shadow levels.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -105,13 +105,6 @@ extern void
SHADOW_INTERNAL_NAME(sh_guest_get_eff_l1e, GUES
... to distinguish it from its non-compat counterpart.
Signed-off-by: Jan Beulich
---
TBD: Perhaps replace by a more generic patch adding .file to all compat/*.c
files?
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -23,8 +23,7 @@ struct get_reserved_device_memory {
u
They (as a now being removed comment validly says) depend only on Xen's
number of page table levels, and hence their tags didn't serve any
useful purpose (there could only ever be one instance in a single
binary, even back in the x86-32 days).
Further conditionalize the inclusion of PV-specific ho
On 20/10/2015 11:05, Julien Grall wrote:
Thank you for the log. The offending node is /pci@ee09/usb@0,1 which
is (r8a7790.dtsi):
1407 usb@0,1 {
1408 reg = <0x800 0 0 0 0>;
1409 device_type = "pci";
1410 p
Hi Kevin,
Would you comment on the two patches?
Thanks,
-Kai
On 10/20/2015 10:34 AM, Kai Huang wrote:
Patch 1 is the v2 of defering enabling of EPT A/D bit until PML get enabled,
with comments from Jan in v1 addressed. Patch 2 is coding style fix of
for_each_vcpu to existing PML functions acco
This run is configured for baseline tests only.
flight 38181 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38181/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-xsm 3 host-install(3)
One step closer, thanks again!
Removing the incompatible PCI/USB devices lets Xen boot somewhat further.
Here is the (significant) difference in log output, the full new one is
appended.
I've back traced the trap message from traps.c +2447:
None of the explicit 'goto bad_data_abort;' calls is r
flight 63067 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2
fail in 63030 REGR. vs. 6
Adding "ranges;" is a good idea and helps, but gives the same error from
traps.c +2447.
On a side-note, adding "ranges;" implicates propagating "#address-cells", and
"#size-cells" values down the DT into the leafs.
-Ursprüngliche Nachricht-
Von: xen-devel-boun...@lists.xen.org [mailto:
flight 38182 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38182/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf 3 host-install(3) broken like 38164
build-armhf-pv
On Mon, 19 Oct 2015, Laszlo Ersek wrote:
> On 10/16/15 21:09, Laszlo Ersek wrote:
> > On 10/16/15 13:34, Fabio Fantoni wrote:
> >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
> >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
> Il 16/10/2015 12:13, Anthony PERARD ha scritto:
> > On Fr
On 20/10/2015 11:51, Jan Beulich wrote:
On 19.10.15 at 18:25, wrote:
>> On 10/19/2015 06:16 AM, John Doe wrote:
> [0.00] general protection fault: [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
>> 4.1.9-6.pvops.q
Hi Anthony,
/var/log/libvirt/libvirtd.log is empty, there is no log.
these are the processes that are running related to xen
ubuntu@arm64:~$ ps -aux | grep xen
root16 0.0 0.0 0 0 ?S 1969 0:00 [xenwatch]
root17 0.0 0.0 0 0 ?S 1969
Hello,
I tried to boot a Windows 8.1 with Hyper-v role as domU.
I had this three options in my config file :
- hap=1
- nestedhvm=1
- cpuid = ['0x1:ecx=0xxx']
I add the patch http://www.gossamer-threads.com/lists/xen/devel/316993
<
Hi,alls
I know the snapshot of xen-4.4.1 is through the function xc_domain_save()
to achieve.But I want to know from executing the command "xl save" to
executing the function xc_domain_save(),how it is call.
Has anybody can tell me the call relationship from python to C about
snapshot?
Thanks
__
To properly support NDIS RSS, the Windows frontend PV driver needs the
Toeplitz hash value calculated by the backend (otherwise it would have to
duplicate the calculation).
This patch adds documentation for "feature-hash" and a definition of a
new XEN_NETIF_EXTRA_TYPE_HASH extra info segment.
Sig
This patch specifies the xenstore keys that should be used by frontends
and backends to negotiate a particular hash algorithm and queue mapping
to be used for mult-queue packet steering on the guest receive side.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc:
This series makes several modifications to netif.h in anticipation of
implementing NDIS RSS support in the Windows frontend driver.
Patch #1 documents the (sad) reality of the netif_rx_request/response
protocol, which has been long overdue.
Patch #2 adds a definition of the NETRXF_gso_prefix flag
Now that requests and response types and extra info segments are
documented in block comments, we can get rid of the inline comments
in the structures. This has the happy side-effect of making the Linux
checkpatch.pl script make fewer complaints after import.
This patch also fixes a small whitespa
This flag is defined here only for compatibility with the Linux variant of
this header. The feature has never been documented and should be
considered deprecated.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
xen/include/publ
Because GSO metadata is passed from backend to frontend using
netif_extra_info segments, which do not carry information stating which
netif_rx_request_t was consumed to free up their slot, frontends must
assume some form of identity relation between ring slot and request.
Hence, so that it is able
flight 63070 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 62101
R
At 04:39 -0600 on 20 Oct (1445315964), Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel ma
At 04:43 -0600 on 20 Oct (1445316214), Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/10/15 11:39, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
In principle, a very good idea.
Is it perhaps worth having the build runes pass in a -D value instead,
At 04:44 -0600 on 20 Oct (1445316259), Jan Beulich wrote:
> Instead of the misleading _guest_ ones use _sh_,
> expressing their sole dependency on the number of shadow levels.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel mailing
On 10/20/15 13:59, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, Laszlo Ersek wrote:
>> On 10/16/15 21:09, Laszlo Ersek wrote:
>>> On 10/16/15 13:34, Fabio Fantoni wrote:
Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>> Il 16/10/2015
On 20/10/15 11:40, Jan Beulich wrote:
> ... to eliminate the resulting duplicate symbols. This includes
> dropping an odd per-CPU variable left from 32-bit days: Now that we
> only care about 64-bit builds, converting the uint64_t needing
> passing to a void pointer is no problem anymore.
>
> Since
At 04:45 -0600 on 20 Oct (1445316306), Jan Beulich wrote:
> They (as a now being removed comment validly says) depend only on Xen's
> number of page table levels, and hence their tags didn't serve any
> useful purpose (there could only ever be one instance in a single
> binary, even back in the x86
On 20/10/15 11:41, Jan Beulich wrote:
> ... to tell them apart by their names even without further context.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/10/15 11:41, Jan Beulich wrote:
> It doesn't depend on GUEST_PAGING_LEVELS.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: To ensure no dependency on GUEST_PAGING_LEVELS, would it perhaps
> be better to move the function to a file compiled just once?
+1 it probably fits best in p2m.c, al
On 10/20/2015 06:28 AM, Stefano Stabellini wrote:
On Mon, 19 Oct 2015, Boris Ostrovsky wrote:
On 10/19/2015 12:55 PM, Stefano Stabellini wrote:
When offlining a cpu, instead of cpu_down, call device_offline, which
also takes care of updating the cpu.dev.offline field. This keeps the
sysfs file
On 20/10/15 11:42, Jan Beulich wrote:
> None of its elements depends on GUEST_PAGING_LEVELS.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
If you do end up making a common.c (as suggested in patch 5), then this
is also a candidate to move, to avoid further issues with multiple
compi
>>> On 20.10.15 at 14:44, wrote:
> On 20/10/15 11:39, Jan Beulich wrote:
>> To make it possible to tell apart the static symbols therein, use their
>> object file names instead of their source ones.
>>
>> Signed-off-by: Jan Beulich
>
> In principle, a very good idea.
>
> Is it perhaps worth hav
>>> On 20.10.15 at 14:54, wrote:
> On 20/10/15 11:41, Jan Beulich wrote:
>> It doesn't depend on GUEST_PAGING_LEVELS.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> TBD: To ensure no dependency on GUEST_PAGING_LEVELS, would it perhaps
>> be better to move the function to a file compiled just onc
On 20/10/15 14:12, Jan Beulich wrote:
On 20.10.15 at 14:44, wrote:
>> On 20/10/15 11:39, Jan Beulich wrote:
>>> To make it possible to tell apart the static symbols therein, use their
>>> object file names instead of their source ones.
>>>
>>> Signed-off-by: Jan Beulich
>> In principle, a ve
On 10/20/2015 08:11 AM, John Doe wrote:
On 20/10/2015 11:51, Jan Beulich wrote:
On 19.10.15 at 18:25, wrote:
On 10/19/2015 06:16 AM, John Doe wrote:
[0.00] general protection fault: [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
On 20/10/15 09:21, Shuai Ruan wrote:
> This patch add basic definitions/helpers which will be used in
> later patches.
>
> Signed-off-by: Shuai Ruan
> Reviewed-by: Andrew Cooper
> ---
> xen/arch/x86/xstate.c | 19 +++
> xen/include/asm-x86/hvm/vcpu.h | 1 +
> xen/incl
>>> On 20.10.15 at 15:22, wrote:
> The reason I think its this commit is that RAX, RDX and RCX look very
> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
> and RAX value is 0x1f, which has two new bits that this commit defined.
That would be the two MPX related bits, ye
On Tue, Oct 20, 2015 at 05:52:30PM +0530, suresh knv wrote:
> /var/log/libvirt/libvirtd.log is empty, there is no log.
You can always increase the log_level in libvirtd.conf (in /etc/libvirt/).
Could you also check your syslog?
> and libvirtd is also running fine
>
> ubuntu@arm64:~$ ps -aux | gr
On 10/20/2015 09:43 AM, Jan Beulich wrote:
On 20.10.15 at 15:22, wrote:
The reason I think its this commit is that RAX, RDX and RCX look very
much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
and RAX value is 0x1f, which has two new bits that this commit defined.
That wou
Wei Liu writes ("Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL"):
> On Sun, Oct 18, 2015 at 05:52:32PM +, osstest service owner wrote:
...
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-xl-qemut-stubdom-debianhvm-a
>>> On 20.10.15 at 16:27, wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
> On 20.10.15 at 15:22, wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
>>> and RAX value is 0x1f, which h
On 10/20/2015 5:41 AM, Jan Beulich wrote:
... to tell them apart by their names even without further context.
Signed-off-by: Jan Beulich
Reviewed-by: Aravind Gopalakrishnan
Thanks,
-Aravind.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
On Tue, 20 Oct 2015, Laszlo Ersek wrote:
> On 10/20/15 13:59, Stefano Stabellini wrote:
> > On Mon, 19 Oct 2015, Laszlo Ersek wrote:
> >> Could that be related to the issue you are experiencing with OVMF?
> >> Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty
> >> paravirt CD-ROM" o
Empty cdroms are not going to connect, avoid waiting for the backend to
switch to state 4, which is never going to happen, and return
EFI_NO_MEDIA instead. Detect an empty cdrom by looking at the "params"
node on xenstore, which is set to "" or "aio:" for empty drives by libxl.
Contributed-under:
On Tue, Oct 20, 2015 at 03:39:26PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL"):
> > On Sun, Oct 18, 2015 at 05:52:32PM +, osstest service owner wrote:
> ...
> > > Tests which did not succeed and are blocking,
> > > including tests wh
Wei Liu writes ("Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL"):
> From mere code inspection and document of lwip 1.3.0 I think mini-os
> does send gratuitous ARP.
The guest is using the PVHVM drivers at this point, with the backend
directly in dom0, so it is the guest's gratuitous a
(1) Please make the subject line say:
OvmfPkg: XenPvBlkDxe: handle empty cdrom drives
On 10/20/15 17:03, Stefano Stabellini wrote:
> Empty cdroms are not going to connect, avoid waiting for the backend to
> switch to state 4, which is never going to happen, and return
> EFI_NO_MEDIA instead.
(
flight 63071 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63071/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like
62041
Tests which d
flight 63085 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 60684
build-i386
flight 63091 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63091/
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 12
Ian Campbell writes ("[PATCH] tools: libxl: allow permissive qemu-upstream pci
passthrough."):
> On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote:
>
> Anyone fancy (n)acking this followup to XSA-131? I think we probably
> want this for 4.6.
I have backported this, and the corresponding doc
Ian Campbell writes ("Backport "tools/console: xenconsole tolerate tty
errors""):
> While looking at Debian bug #794071 I came across this which may or may not
> resolve that bug, but looks like it ought to be backported anywhere that
> XSA-57 was applied.
>
> It is in staging-4.5, but not stagin
1 - 100 of 117 matches
Mail list logo
