>>> On 22.09.17 at 19:50, wrote:
> On 22/09/17 17:15, Jan Beulich wrote:
> On 22.09.17 at 13:41, wrote:
>>> @@ -1672,8 +1670,8 @@ gnttab_grow_table(struct domain *d, unsigned int
>>> req_nr_frames)
>>> ASSERT(gt->active);
>>>
>>> if ( req_nr_frames < INITIAL_NR_GRANT_FRAMES )
>>>
>>> On 22.09.17 at 18:27, wrote:
> On 22/09/17 16:47, Jan Beulich wrote:
> On 22.09.17 at 13:41, wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -929,6 +929,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v,
> uint32_t leaf,
>>> res->b = v->vcpu_id;
* Pavel Machek wrote:
> > For example, there would be collision with regular user-space mappings,
> > right?
> > Can local unprivileged users use mmap(MAP_FIXED) probing to figure out
> > where
> > the kernel lives?
>
> Local unpriviledged users can probably get your secret bits using cache
>>> On 23.09.17 at 00:44, wrote:
> On Fri, 22 Sep 2017, Bhupinder Thakur wrote:
>> DEFINE_XEN_FLEX_RING(xencons) defines common helper functions such as
>> xencons_queued() to tell the current size of the ring buffer,
>> xencons_mask() to mask off the index, which are useful helper functions.
>> p
>>> On 23.09.17 at 17:09, wrote:
> On 23 September 2017 at 18:55, Julien Grall wrote:
>> I was not able to spot why DEFINE_XEN_FLEX_RING would require C99. Can you
>> detail it?
> This macro expands to generate inline functions, which I believe
> require C99 to compile.
Plus there's at least one
>>> On 22.09.17 at 19:20, wrote:
> Signed-off-by: Anthony PERARD
Would you mind clarifying in a brief description whether this is just
routine catch up, or to bring in any specific changes we need?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.
> -Original Message-
> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
> Sent: 23 September 2017 19:57
> To: Paul Durrant ; xen-devel@lists.xen.org
> Cc: Andrew Cooper ; Wei Liu
> ; sstabell...@kernel.org; Ian Jackson
> ; rcojoc...@bitdefender.com;
> konrad.w...@oracle.com;
On Mi, 2017-09-20 at 14:37 +, Paul Durrant wrote:
> >
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 20 September 2017 13:24
> > To: Alexandru Isaila
> > Cc: suravee.suthikulpa...@amd.com; Andrew Cooper
> > ; Paul Durrant
> > ;
> > Wei Liu ; George D
Just like done in d2bd05d88d ("xen-pciback: return proper values during
BAR sizing") for the ROM BAR, ordinary ones also shouldn't compare the
written value directly against ~0, but consider the r/o bits at the
bottom (if any).
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_he
>>> On 30.08.17 at 12:34, wrote:
> @@ -40,11 +44,15 @@ static void __init calculate_hvm_max_policy(void)
> dp->plaform_info.available = true;
> dp->plaform_info.cpuid_faulting = true;
> }
> +
> +/* 0x0140 MSR_INTEL_MISC_FEATURES_ENABLES */
> +vp->misc_features_e
On Fri, Sep 22, 2017 at 01:53:05PM +0530, Bhupinder Thakur wrote:
>
> tools/libxc/include/xenctrl.h | 20 +
> tools/libxc/xc_domain.c | 27 ++
> tools/libxl/libxl_arch.h | 7 ++
> tools/libxl/libxl_arm.c | 27 ++
> tool
On Fri, Sep 22, 2017 at 07:50:04PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 22, 2017 at 05:21:12PM +0100, Euan Harris wrote:
> > xs_fileno() returns a file descriptor which receives events when Xenstore
> > watches fire. Exposing this in the Python bindings is a prerequisite
> > for
Hello Wilk,
I had try Ctrl+a three times and 'd' but no dump on the serial console.
Thanks,
Bharat
On Fri, Sep 22, 2017 at 7:13 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:
> On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote:
> > Hello Wilk,
> >
> > I had try 'console=h
This run is configured for baseline tests only.
flight 72154 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigr
flight 72153 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72153/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a
build-arm64-pvops
On Jo, 2017-09-21 at 06:42 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 21.09.17 at 07:12, wrote:
> > --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> > @@ -6195,7 +6196,7 @@ x86_emulate(
> > /* vpsll{w,d} $imm8,{x,y}mm,{
On Fri, Sep 15, 2017 at 12:39 PM, Wei Liu wrote:
> On Fri, Aug 25, 2017 at 05:43:33PM +0100, George Dunlap wrote:
>> For some reason the 'feof()' check for the file size isn't working in
>> llvm-clang-fast mode; the result is several kilobyte files rather than
>> the 4k limit files as we've reques
flight 113807 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113807/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 113791
REGR. vs. 113387
Te
On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote:
> - Not an issue back then when the patch was made, but as the question earlier
> to Roger,
> the hypervisor seems to grow more interference with pci devices with the
> PVH dom0 work.
> If and hoow does that relate to pci-bac
Instead of attaching the ARM specific grant table data to the domain
structure add it to struct grant_table. Add the needed arch functions
to the asm-*/grant_table.h includes.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich [non-ARM parts]
---
V9:
- correct and clea
Delay the allocation of the grant table sub structures in order to
allow modifying parameters needed for sizing of these structures at a
per domain basis. Allocate the structures and the table frames only
from grant_table_init().
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V10:
-
On very large hosts a pv-guest needs to know whether it will have to
handle frame numbers larger than 32 bits in order to select the
appropriate grant interface version.
Add a new Xen specific CPUID node to contain the maximum machine address
width similar to the x86 CPUID node 0x8008 containi
Currently Linux has no support for grant v2 as this would reduce the
maximum number of active grants by a factor of 2 compared to v1,
because the number of possible grants are limited by the allowed number
of grant frames and grant entries of v2 need twice as much bytes as
those of v1.
Unfortunate
Add the maximum possible mfn of the host to the libxl_physinfo
data structure.
Signed-off-by: Juergen Gross
Acked-by: Ian Jackson
---
tools/libxl/libxl.c | 1 +
tools/libxl/libxl.h | 9 +
tools/libxl/libxl_types.idl | 1 +
3 files changed, 11 insertions(+)
diff --git a/
Add xl.conf config items for default values of grant limits:
max_grant_frames will set the default for the maximum number of grant
frames for a domain which will take effect if the domain's config file
doesn't specify a value. If max_grant_frames isn't set in xl.conf it
will default to 32 for host
Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
anything about the sub-leaf semantics.
Add comments to clarify the interface.
Signed-off-by: Juergen Gross
---
xen/include/public/arch-x86/cpuid.h | 20 +
Add a new libxc function xc_domain_set_gnttbl_limits() setting the
limits for the maximum numbers of grant table frames and maptrack
frames of a domain.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
V4:
- use domid_t (Wei Liu)
---
tools/lib
When creating a Xenstore stubdom set the grant limits: the stubdom
will need to setup a very limited amount of grants only, so 4 grant
frames are enough. For being able to support up to 32768 domains it
will need 128 maptrack frames (1 mapping per domain, 256 maptrack
entries per maptrack frame).
Add new domain config items for setting the limits for the maximum
numbers of grant table frames and maptrack frames of a domain.
Signed-off-by: Juergen Gross
Acked-by: Ian Jackson
---
V6:
- made set_gnttab_limits hypercall mandatory, taking defaults from
xl.conf
V4:
- rename configuration it
Add a function for obtaining the highest possible physical memory
address of the system. This value is influenced by:
- hypervisor configuration (CONFIG_BIGMEM)
- processor capability (max. addressable physical memory)
- memory map at boot time
- memory hotplug capability
Add this value to xen_sy
Instead of using the same global resource limits of grant tables (max.
number of grant frames, max. number of maptrack frames) for all domains
make these limits per domain. Set those per-domain limits in
grant_table_set_limits(). The global settings are serving as an upper
boundary now which must n
PIE may (and commonly will) result in the binary being loaded above the
4Gb boundary, which can't work with at least the VZEROUPPER compat mode
test.
Reported-by: Wei Liu
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -98,7 +98,8 @@
>>> On 25.09.17 at 12:00, wrote:
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Allocate the structures and the table frames only
> from grant_table_init().
>
> Signed-off-by: Juergen
>>> On 25.09.17 at 12:00, wrote:
> @@ -96,14 +96,15 @@ struct xen_sysctl_physinfo {
> uint32_t nr_nodes;/* # nodes currently online */
> uint32_t max_node_id; /* Largest possible node ID on this host */
> uint32_t cpu_khz;
> +uint32_t capabilities; /* XEN_SYSCTL_PHYSCAP_???
>>> On 25.09.17 at 11:16, wrote:
> @@ -7750,6 +7742,9 @@ x86_emulate(
> unimplemented_insn:
> rc = X86EMUL_UNIMPLEMENTED;
> goto done;
> +unrecognized_insn:
> +rc = X86EMUL_UNRECOGNIZED;
> +goto done;
> }
> Do you find this approach OK?
Yes, that's
PIE may (and commonly will) result in the binary being loaded above
the 4Gb boundary, which can't work with at least the VZEROUPPER compat
mode test.
Reported-by: Wei Liu
Signed-off-by: Jan Beulich
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
With this patch, vzeroupper passe
The deprecation involves generating a function that copies the
deprecated fields into it's new location if the new location has not
been set.
The fields that are going to be shared between PVH and HVM or between
PVH and PV are moved to the top level of libxl_domain_build_info, and
the old location
Hello,
This series adds a new PVH guest type to libxl/xl, this supersedes the
current PVHv2 implementation that relies on using the "none" device
model version.
As part of this series a new xl option is also implemented, called
"type" that supersedes the current "builder" option. A "firmware"
opt
This is required because those options will be used by the new PVH
guest type, and thus need to be shared between PV and HVM.
Defines are added in order to signal consumers that the fields are
available.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl.h
The new firmware option aims to provide a coherent way to set the
firmware for the different kind of guests Xen supports.
For PV guests the available firmwares are pvgrub{32|64}, and for HVM
the following are supported: bios, uefi, seabios, rombios and ovmf.
Note that uefi maps to ovmf, and bios m
The new guest type is introduced to the libxl IDL. libxl__domain_make
is also modified to save the guest type, and libxl__domain_type is
expanded to fetch that information when detecting guest type.
This is required because the hypervisor only differentiates between PV
and HVM guests, so libxl nee
Code movement in preparation for making the bootloader,
bootloader_args, nested_hvm and timer_mode fields shared between all
guests types. While moving the code, limit the line-length to 80
columns.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
Change
Those types are missing a helper to check whether a definition of the
type holds the default value. This will be required by a later patch
that will implement deprecation of fields inside of a libxl type.
Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
Acked-by: Wei Liu
---
Cc: Ian Jackson
Allow PVH guests to boot using a bootloader.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_bootloader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index a47bd8c25
Introduce a new type option to xl configuration files in order to
specify the domain type. This supersedes the current builder option.
The new option is documented in the xl.cfg man page, and the previous
builder option is marked as deprecated.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
PVH guests use the same device model selection as PV guests, because
PVH guests only use the device model for the PV backends.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_dm.c
Remove the device model "none" support from domain creation and
introduce support for PVH.
This requires changing some of the HVM checks to be applied for both
HVM and PVH.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_create.c | 71 +
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_console.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 624bd016c6..32c3ec7d7b 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/li
And remove the device model "none" support.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_dom_save.c| 9 ++---
tools/libxl/libxl_dom_suspend.c | 8 +++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_dom_save.
And remove support for device model "none".
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_domain.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 08eccd
And remove device model "none" support.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_dom.c | 149 ++--
1 file changed, 95 insertions(+), 54 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl
Remove device model "none" support from the nic functions.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_nic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index cf8fd5c237..2
CD-ROM backend selection was partially based on the device model, this
is no longer needed since the device model "none" is now removed, so
HVM guests always have a device model.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_disk.c | 10 +-
1 file
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_mem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index f5d2530d8c..e551e09fed 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -46
This also includes the x86 ACPI related functions. Remove support for
device model "none"
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_x86.c | 33 +
tools/libxl/libxl_x86_acpi.c | 3 +--
2 files changed, 18 insertion
Add PVH support to usb related functions.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 1d5a2432ba..cb0e792724 100644
---
Remove the usage of device model "none" in the migration stream
related functions.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxl/libxl_stream_read.c | 6 ++
tools/libxl/libxl_stream_write.c | 11 ++-
2 files changed, 4 insertions(+), 13 deletions(
And the xl.cfg man page documentation.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
docs/man/xl.cfg.pod.5.in| 5 -
tools/libxl/libxl.h | 8
tools/libxl/libxl_types.idl | 1 -
3 files changed, 14 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in
And remove device model "none".
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/xl/xl_parse.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 9f9e810c64..fb26db2e1c 100644
--- a/tools/xl/xl_parse.
On Mon, Sep 25, 2017 at 10:36 AM, George Dunlap
wrote:
> On Fri, Sep 15, 2017 at 12:39 PM, Wei Liu wrote:
>> On Fri, Aug 25, 2017 at 05:43:33PM +0100, George Dunlap wrote:
>>> For some reason the 'feof()' check for the file size isn't working in
>>> llvm-clang-fast mode; the result is several kil
flight 113810 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113810/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf baaa3cee1eafc044606ee9dc60ec091713f81b8b
baseline version:
ovmf e921f58d44587c77b843a
On Mon, Sep 25, 2017 at 08:01:01AM +, Jan Beulich wrote:
> Just like done in d2bd05d88d ("xen-pciback: return proper values during
> BAR sizing") for the ROM BAR, ordinary ones also shouldn't compare the
> written value directly against ~0, but consider the r/o bits at the
> bottom (if any).
>
On Fri, Aug 25, 2017 at 6:45 PM, Andrew Cooper
wrote:
> On 25/08/17 17:43, George Dunlap wrote:
>> Rather than open-coding the "read" from the input file.
>>
>> Signed-off-by: George Dunlap
>
> This patch fills me with dread.
>
> How about data_read() and data_available() which are slightly more
On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
> >>> On 25.09.17 at 12:49, wrote:
> > PIE may (and commonly will) result in the binary being loaded above
> > the 4Gb boundary, which can't work with at least the VZEROUPPER compat
> > mode test.
> >
> > Reported-by: Wei Liu
> > Signe
flight 113811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113811/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 25.09.17 at 12:00, wrote:
> Instead of using the same global resource limits of grant tables (max.
> number of grant frames, max. number of maptrack frames) for all domains
> make these limits per domain. Set those per-domain limits in
> grant_table_set_limits(). The global settings are ser
>>> On 25.09.17 at 13:43, wrote:
> On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> >>> On 25.09.17 at 12:49, wrote:
>> > PIE may (and commonly will) result in the binary being loaded above
>> > the 4Gb boundary, which can't work with at least the VZEROUPPER compat
>> > mode test.
>>> On 25.09.17 at 12:49, wrote:
> PIE may (and commonly will) result in the binary being loaded above
> the 4Gb boundary, which can't work with at least the VZEROUPPER compat
> mode test.
>
> Reported-by: Wei Liu
> Signed-off-by: Jan Beulich
> Signed-off-by: Wei Liu
> ---
> Cc: Jan Beulich
>
On 25/09/17 11:00, Juergen Gross wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
>
> Add a new Xen specific CPUID node to contain the maximum machine address
> widt
>>> On 25.09.17 at 12:00, wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
>
> Add a new Xen specific CPUID node to contain the maximum machine address
> width sim
>>> On 25.09.17 at 12:00, wrote:
> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
> anything about the sub-leaf semantics.
>
> Add comments to clarify the interface.
>
> Signed-off-by: Juergen Gross
Acked-
On 25/09/17 13:55, Andrew Cooper wrote:
> On 25/09/17 11:00, Juergen Gross wrote:
>> On very large hosts a pv-guest needs to know whether it will have to
>> handle frame numbers larger than 32 bits in order to select the
>> appropriate grant interface version.
>>
>> Add a new Xen specific CPUID nod
On 25/09/17 13:00, Juergen Gross wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface v
This patchset implements a mechanism which allows XEN to send first an event
if the emulator encountered an unsupported instruction.
The monitor application can choose to mitigate the error, for example to
singlestep
the instruction using the real processor and then resume execution of the normal
Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.
This value should only be returned by the core emulator only if it fails to
properly decode the current instruction's opc
- print the return code of the last failed emulator operation
in hvm_dump_emulation_state.
- print the return code in sh_page_fault (SHADOW_PRINTK) to make the
distiction between X86EMUL_UNHANDLEABLE and X86EMUL_UNIMPLEMENTED.
Signed-off-by: Petre Pircalabu
Reviewed-by: Jan Beulich
---
Changed
If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. a
>>> On 25.09.17 at 14:00, wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface version
On Wed, Sep 20, Stefano Stabellini wrote:
> From: Olaf Hering
> g_malloc0_n is available since glib-2.24. To allow build with older glib
> versions use the generic g_new0, which is already used in many other
> places in the code.
> Fixes commit 3284fad728 ("xen-disk: add support for multi-page sh
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
Hello Bharat,
On 25.09.17 11:42, bharat gohil wrote:
Hello Wilk,
I had try Ctrl+a three times and 'd' but no dump on the serial console.
Its a way to switch to XEN debug console. In case you are using minicom,
you should press Ctrl+A six times, then you will see the line like
following:
flight 113809 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113809/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113765
test-amd64-i386-xl-qemut-win
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
Thanks,
Bharat
On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov
wrote:
> Hello Bharat,
>
>
> On 25.09.17 11:42, bharat gohil wrote:
>
>> Hello Wilk,
>>
>> I had try Ctrl+a three times and 'd' but no dump on the serial console.
>
On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
> >>> On 25.09.17 at 13:43, wrote:
> > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
> >> >>> On 25.09.17 at 12:49, wrote:
> >> > PIE may (and commonly will) result in the binary being loaded above
> >> > the 4Gb boundary
>>> On 18.09.17 at 17:31, wrote:
> In the case where a PV domain is mapping guest resources then it needs make
> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
> domid, so that the passed in gmfn values are correctly treated as mfns
> rather than gfns present in the guest p
>>> On 25.09.17 at 14:55, wrote:
> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
>> >>> On 25.09.17 at 13:43, wrote:
>> > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> >> >>> On 25.09.17 at 12:49, wrote:
>> >> > PIE may (and commonly will) result in the binary be
On Mon, Sep 25, 2017 at 01:55:03PM +0100, Wei Liu wrote:
> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
> > >>> On 25.09.17 at 13:43, wrote:
> > > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
> > >> >>> On 25.09.17 at 12:49, wrote:
> > >> > PIE may (and commonly wi
>>> On 25.09.17 at 15:01, wrote:
> On Mon, Sep 25, 2017 at 01:55:03PM +0100, Wei Liu wrote:
>> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
>> > >>> On 25.09.17 at 13:43, wrote:
>> > > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> > >> >>> On 25.09.17 at 12:49,
This run is configured for baseline tests only.
flight 72155 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72155/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf baaa3cee1eafc044606ee9dc60ec091713f81b8b
baseline v
On Mon, Sep 25, 2017 at 07:09:51AM -0600, Jan Beulich wrote:
> > The build rune is in fact using HOSTCC to link the executable, hence we
> > need -fno-pie.
> >
This should be "we need -no-pie", sorry.
> > I'm not sure why omitting -fno-PIE is not a problem, but it works.
>
> All pretty confusin
On Mon, Sep 25, 2017 at 07:16:43AM -0600, Jan Beulich wrote:
> >
> > Actually I do have a wheezy chroot to verify that:
> >
> > (wheezy)wei@zion:/local/work$ gcc --version
> > gcc (Debian 4.6.3-14) 4.6.3
> >
> > (wheezy)wei@zion:/local/work$ gcc -no-pie
> > gcc: error: unrecognized option '-no-p
Hello Bharat,
On 25.09.17 15:53, bharat gohil wrote:
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
Or your dom0 kernel disabled serial port clock. Because from kernel
point of view it is left unused, like it happened to us with R-Car gen3
SoC. So we issued such a patch
Hi,
On 09/25/2017 01:53 PM, bharat gohil wrote:
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
I am a bit confused... on one of the previous e-mail you posted log from
Xen:
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed
On 25/09/17 14:02, Jan Beulich wrote:
On 18.09.17 at 17:31, wrote:
>> In the case where a PV domain is mapping guest resources then it needs make
>> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
>> domid, so that the passed in gmfn values are correctly treated as mfns
PIE may (and commonly will) result in the binary being loaded above
the 4Gb boundary, which can't work with at least the VZEROUPPER compat
mode test.
Add -no-pie when appropriate so that linker won't generate a PIE
executable.
Reported-by: Wei Liu
Signed-off-by: Jan Beulich
Signed-off-by: Wei L
>>> On 18.09.17 at 17:31, wrote:
> Certain memory resources associated with a guest are not necessarily
> present in the guest P2M and so are not necessarily available to be
> foreign-mapped by a tools domain unless they are inserted, which risks
> shattering a super-page mapping.
For grant table
>>> On 25.09.17 at 15:40, wrote:
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -76,7 +76,7 @@ $(addsuffix .c,$(SIMD)) $(addsuffix -avx.c,$(filter
> sse%,$(SIMD))):
> ln -sf simd.c $@
>
> $(TARGET): x86_emulate.o test_x86_emulator.o
> - $(HOS
Ping?
On 06/09/17 19:36, Juergen Gross wrote:
> With virt_spin_lock() being guarded by a static key the bare metal case
> can be optimized by patching the call away completely. In case a kernel
> running as a guest it can decide whether to use paravitualized
> spinlocks, the current fallback to th
1 - 100 of 167 matches
Mail list logo
