flight 60616 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60616/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 59059
Tests which did not succeed,
flight 60614 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
Regressions which are
flight 60615 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60615/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf c3db5a8c3d3acf4791844c10b89a60552ac3c350
baseline version:
ovmf 8ca1489ba63753f3dfd6552fd7a2c1f4f64
I think I've stated clearly what I want to do.
|I want to locate the hypercall page address when creating a new domU, so
as to locate hypercalls. Is it possible?
2015-08-07 21:06 GMT+08:00 Andrew Cooper :
> On 07/08/15 02:52, big strong wrote:
>
> Or how can I get the address of hypercall page b
On Fri, 2015-08-07 at 16:26 -0700, Luis R. Rodriguez wrote:
> On Fri, Aug 7, 2015 at 4:08 PM, Toshi Kani wrote:
> > On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:
> > > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
> > > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrot
On Fri, Aug 7, 2015 at 4:08 PM, Toshi Kani wrote:
> On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:
>> On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
>> > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
>> > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
>> > > >
On Fri, 2015-08-07 at 17:08 -0600, Toshi Kani wrote:
> On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:
> > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
> > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani
> > > > wr
On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:
> On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
> > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
> > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
> > > > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrot
flight 60611 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60611/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 60207
Tests which did
On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
> On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
>> On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
>> > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
>> > > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote:
>> > > >
On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
> On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
> > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
> > > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote:
> > > > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
>
On Fri, Aug 07, 2015 at 07:53:55PM +0100, Julien Grall wrote:
> The grants are based on the Xen granularity (i.e 4KB). While the function
> to map grants for Linux (linux_gnttab_grant_map) is using the correct
> size (XC_PAGE_SIZE), the unmap one (linux_gnttab_munmap) is using
> getpagesize().
>
>
On 08/07/2015 12:34 PM, Julien Grall wrote:
The variable xen_store_mfn is effectively storing a GFN and not an MFN.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I think that the assignation of xen_start_info in
xenstored_local_ini
flight 60612 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60612/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-i
flight 60609 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60609/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60165
Tests which did not succeed, but a
setup_frametable_mappings() rounds frametable_size up to a multiple
of 32MB. This is wasteful on systems with less than 4GB of RAM,
although it does allow the "contig" bit to be set in the PTEs.
Where the frametable is less than 32MB in size, instead round up
to a multiple of 2MB, not setting the
On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
> On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
>> On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote:
>> > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
>> > > > > > On 12.06.15 at 01:23, wrote:
>> > > > There are two usages
On 07/08/15 11:18, Roger Pau Monne wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
> VCPUOP_is_up hypercalls from HVM guests.
>
> This patch introduces a new structure (vcpu_hvm_context) that should be used
> in conjuction with the VCPUOP_initialise hypercall in order
The grants are based on the Xen granularity (i.e 4KB). While the function
to map grants for Linux (linux_gnttab_grant_map) is using the correct
size (XC_PAGE_SIZE), the unmap one (linux_gnttab_munmap) is using
getpagesize().
On domain using a page granularity different than Xen (this is the case
f
On 07/08/15 17:24, Wei Liu wrote:
> On Fri, Aug 07, 2015 at 05:51:02PM +0200, Roger Pau Monné wrote:
> [...]
It is recommended to accept the default value for new guests. If
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 1599de4..d67feb0 100644
--- a/to
On 07/08/15 16:57, Roger Pau Monné wrote:
> El 07/08/15 a les 17.18, Konrad Rzeszutek Wilk ha escrit:
>> On Fri, Aug 07, 2015 at 12:18:08PM +0200, Roger Pau Monne wrote:
>>> Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
>>> builder now uses the PV xc_dom_* set of func
On 07/08/15 11:18, Roger Pau Monne wrote:
> Allow xc_dom_elfloader to report a guest type as hvm-3.0-x86_32 if it's
> running inside of a HVM container and has the PHYS32_ENTRY elfnote set.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: We
>> OOI, you win 30MB of RAM but how does this affect the performance?
>
> Fair question. :-) All I can say is that I don't see any noticeable
> difference on my system.
> Are there performance tests that you suggest I run ?
> Also, note that the new code is
> only executed if you specify a previou
On Tue, Jul 28, 2015 at 4:15 AM, Dario Faggioli
wrote:
> On Fri, 2015-07-10 at 23:52 -0500, Chong Li wrote:
>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index e9a2d26..9f7f859 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>>
>> +static int sched_rtds_validate_
On 07/08/15 11:18, Roger Pau Monne wrote:
> This HVM parameter returns a PFN that contains the address of the memory
> page where the guest command line has been placed.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
> Cc: Jan Beu
Hi Julien,
Thanks for the review.
> OOI, you win 30MB of RAM but how does this affect the performance?
Fair question. :-) All I can say is that I don't see any noticeable difference
on my
system. Are there performance tests that you suggest I run ? Also, note that
the new code is only executed
The firmware directory is not built at all on ARM. Attempting to update
it using the target subtree-force-update will fail when try to update
seabios.
Signed-off-by: Julien Grall
---
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
I've noticed it while trying to upda
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying o
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the gran
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of the
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_gfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_gfn to make this explicit.
We also allocate a 64KB page for the shared
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver will
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v3:
- Some changes has been m
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with multiple
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste f
On 07/08/15 17:46, Julien Grall wrote:
> Hi all,
>
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest c
Docker and containers have gotten a lot of attention lately for their
small size and easy deployment. But Unikernels offer even smaller
sizes and huge advances in security! In the next generation of cloud,
these are critical assets, so it is no wonder that Unikernels are
beginning to draw serious i
I have started looking at what would be required. It looks like a full
graphical stack implementation, including userland, kernelmode, and
possibly even VGA device code. For these reasons, I think it will be a
large undertaking and want to discuss with the community.
I think some of what Qubes did
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux page definition in Xen drivers.
Introduce Xen page definition helpers based on the Linux page
de
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest with 64KB pages enabled will result to a
guest crash.
This series is a first attempt to allow those
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used to
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct ex
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge to split the Linux page into grants and
call a function given by the caller on each gra
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
---
Cc: Ian Campbell
Cc: Wei Liu
Cc: net...@vger.kernel.org
Changes in v2:
- Patch added
---
drivers/net/xen-netback/netback.c | 14
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszu
Many PV drivers contain the idiom:
pfn = page_to_gfn(...) /* Or similar */
gnttab_grant_foreign_access_ref
Replace it by a new helper. Note that when Linux is using a different
page granularity than Xen, the helper only gives access to the first 4KB
grant.
This is useful where drivers are alloca
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
---
Stefano Stabellini
Russell King
Changes in v3:
On Fri, Aug 07, 2015 at 12:18:00PM +0200, Roger Pau Monne wrote:
> This new elfnote contains the 32bit entry point into the kernel. Xen will
> use this entry point in order to launch the guest kernel in 32bit protected
> mode with paging disabled.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jack
On Fri, Aug 07, 2015 at 12:19:13PM -0400, hanji unit wrote:
> Hello, I am planning to develop inter-domain graphical window
> forwarding, as it is a critical piece of Xen that is missing, that
> other Hypervisors have (such as VMWare Unity Mode and VirtualBox
> Seamless Mode). Searching around on t
On 07/08/15 11:18, Roger Pau Monne wrote:
> This new elfnote contains the 32bit entry point into the kernel. Xen will
> use this entry point in order to launch the guest kernel in 32bit protected
> mode with paging disabled.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Stefano Stabe
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.
For instance, with pfn_to_mfn, we expect to
After the commit introducing convertion between DMA and guest addresses,
all the callers of pfn_to_mfn are expecting to get a GFN (Guest Frame
Number). On ARM, all the guests are auto-translated so the GFN is equal
to the Linux PFN (Pseudo-physical Frame Number).
The current implementation may ret
On 07/08/15 11:18, Roger Pau Monne wrote:
> @@ -1336,7 +1343,8 @@ static int meminit_hvm(struct xc_dom_image *dom)
> * tot_pages will be target_pages - VGA_HOLE_SIZE after
> * this call.
> */
> -rc = xc_domain_set_pod_target(xch, domid, target_pages -
> VGA_HO
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valke
ARM guests are always HVM. The current implementation is assuming a 1:1
mapping which is only true for DOM0 and may not be at all in the future.
Furthermore, all the helpers but arbitrary_virt_to_machine are used in
x86 specific code (or only compiled for).
The helper arbitrary_virt_to_machine is
Hi all,
This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.
The differences from v2 is minor but I resent it because my 64K series depends
on this series.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first
The swiotlb is required when programming a DMA address on ARM when a
device is not protected by an IOMMU.
In this case, the DMA address should always be equal to the machine address.
For DOM0 memory, Xen ensure it by have an identity mapping between the
guest address and host address. However, whe
The privcmd code is mixing the usage of GFN and MFN within the same
functions which make the code difficult to understand when you only work
with auto-translated guests.
The privcmd driver is only dealing with GFN so replace all the mention
of MFN into GFN.
The ioctl structure used to map foreign
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
The variable xen_store_mfn is effectively storing a GFN and not an MFN.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I think that the assignation of xen_start_info in
xenstored_local_init is pointless. Although I haven't drop it just
All the caller of xen_tmem_{get,put}_page have a struct page * in hand
and call pfn_to_gfn for the only benefits of these 2 functions.
Rather than passing the pfn in parameter, pass directly the page and use
directly xen_page_to_gfn.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
On Mon, Jul 27, 2015 at 11:11 AM, Dario Faggioli
wrote:
> On Fri, 2015-07-10 at 23:52 -0500, Chong Li wrote:
>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index d1d2ab3..58f1a7a 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.
On 07/08/15 11:17, Roger Pau Monne wrote:
> Only allow enabling or disabling all the emulated devices inside of Xen,
> right now Xen doesn't support enabling specific emulated devices only.
>
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/domain.c |
On 07/08/15 11:17, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> Cc: Boris Ostrovsky
> Cc: Suravee Suthikulpanit
> Cc: Aravind Gopalakrishnan
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Jun Nakajima
> Cc: Eddie Dong
> Cc: Kevin Tian
> ---
Patches 13 - 21 (all the "allow disabl
On Fri, Aug 07, 2015 at 05:51:02PM +0200, Roger Pau Monné wrote:
[...]
> >> It is recommended to accept the default value for new guests. If
> >> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> >> index 1599de4..d67feb0 100644
> >> --- a/tools/libxc/xc_dom_x86.c
> >> +++ b/tool
El 07/08/15 a les 18.11, Boris Ostrovsky ha escrit:
> On 08/07/2015 11:41 AM, Roger Pau Monné wrote:
>> El 07/08/15 a les 16.09, Boris Ostrovsky ha escrit:
>>> On 08/07/2015 06:17 AM, Roger Pau Monne wrote:
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a0a97
Hello, I am planning to develop inter-domain graphical window
forwarding, as it is a critical piece of Xen that is missing, that
other Hypervisors have (such as VMWare Unity Mode and VirtualBox
Seamless Mode). Searching around on the internet, I see that there is
no current support for such a featu
On 08/07/2015 11:41 AM, Roger Pau Monné wrote:
El 07/08/15 a les 16.09, Boris Ostrovsky ha escrit:
On 08/07/2015 06:17 AM, Roger Pau Monne wrote:
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a0a97e7..5acb246 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch
This is a simple fix to make sure libxl__build_hvm returns an error code in
case of failure.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
I would rather prefer to have it fixed in a proper way like it's done in my
"libxl: fix libxl__bu
On 07/08/15 11:17, Roger Pau Monne wrote:
> Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
> disabling specific devices emulated inside of Xen for HVM guests.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
On 08/07/2015 11:50 AM, Julien Grall wrote:
Hi,
On 07/08/15 16:35, David Vrabel wrote:
On 02/07/15 15:53, Boris Ostrovsky wrote:
I haven't posted Linux part of PV(H) VPMU support in a while but now
that (hopefully) the hypervisor part is getting close to be done I
think it's time to post it ag
El 07/08/15 a les 17.55, Wei Liu ha escrit:
> On Fri, Aug 07, 2015 at 05:44:22PM +0200, Roger Pau Monné wrote:
>> El 07/08/15 a les 14.22, Wei Liu ha escrit:
>>> On Fri, Aug 07, 2015 at 12:18:02PM +0200, Roger Pau Monne wrote:
Enable this hypercall for HVM guests in order to fetch the e820 mem
On 07/08/15 11:17, Roger Pau Monne wrote:
> Remove xc_hvm_build_x86.c and xc_hvm_build_arm.c since xc_hvm_build is not
> longer used in order to create HVM guests.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
Even more slimming
On 07/08/15 11:17, Roger Pau Monne wrote:
> +static void build_hvm_info(void *hvm_info_page, struct xc_dom_image *dom)
> +{
> +struct hvm_info_table *hvm_info = (struct hvm_info_table *)
> +(((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> +uint8_t sum;
> +int i;
> +
> +
El 07/08/15 a les 17.18, Konrad Rzeszutek Wilk ha escrit:
> On Fri, Aug 07, 2015 at 12:18:08PM +0200, Roger Pau Monne wrote:
>> Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
>> builder now uses the PV xc_dom_* set of functions this kernel will be parsed
>> and loaded
On Fri, Aug 07, 2015 at 05:44:22PM +0200, Roger Pau Monné wrote:
> El 07/08/15 a les 14.22, Wei Liu ha escrit:
> > On Fri, Aug 07, 2015 at 12:18:02PM +0200, Roger Pau Monne wrote:
> >> Enable this hypercall for HVM guests in order to fetch the e820 memory
> >> map in the absence of an emulated BIOS
Hi,
On 07/08/15 16:35, David Vrabel wrote:
> On 02/07/15 15:53, Boris Ostrovsky wrote:
>> I haven't posted Linux part of PV(H) VPMU support in a while but now
>> that (hopefully) the hypervisor part is getting close to be done I
>> think it's time to post it again.
>>
>> There are very few differe
El 07/08/15 a les 14.58, Wei Liu ha escrit:
> On Fri, Aug 07, 2015 at 12:18:08PM +0200, Roger Pau Monne wrote:
>> Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
>> builder now uses the PV xc_dom_* set of functions this kernel will be parsed
>> and loaded inside the gue
On Mon, Jul 27, 2015 at 10:14 AM, Dario Faggioli
wrote:
> On Fri, 2015-07-10 at 23:52 -0500, Chong Li wrote:
>
>
> Or by "just" adding a note before the actual output:
>
> # xl sched-rtds -d vm1
> Showing per-vm(s) default scheduling parameters,
> use `-v' for seeing the actual parameters of
El 07/08/15 a les 14.22, Wei Liu ha escrit:
> On Fri, Aug 07, 2015 at 12:18:02PM +0200, Roger Pau Monne wrote:
>> Enable this hypercall for HVM guests in order to fetch the e820 memory
>> map in the absence of an emulated BIOS. The memory map is populated and
>> notified to Xen in arch_setup_memini
El 07/08/15 a les 16.09, Boris Ostrovsky ha escrit:
> On 08/07/2015 06:17 AM, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index a0a97e7..5acb246 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -1027,6 +10
On Mon, Jul 27, 2015 at 03:19:56PM +0200, Fabio Fantoni wrote:
> Il 23/07/2015 19:08, Stefano Stabellini ha scritto:
> >Try to use "xen-qemudepriv-domid$domid" first, then
> >"xen-qemudepriv-shared" and root if everything else fails.
> >
> >The uids need to be manually created by the user or, more
= Issue / Observation =
The information about the release schedule is not clearly published
anywhere apart from the mailing lists, which makes it hard for
non-developers (or even for developers) given that the mailing list
traffic for xen-devel is high.
= Possible Solution / Improvement =
Publis
On 02/07/15 15:53, Boris Ostrovsky wrote:
> I haven't posted Linux part of PV(H) VPMU support in a while but now
> that (hopefully) the hypervisor part is getting close to be done I
> think it's time to post it again.
>
> There are very few differences compared to the last version, mostly due
> to
On Thu, Jul 23, 2015 at 06:08:02PM +0100, Stefano Stabellini wrote:
[...]
> +For security reasons, libxl tries to pass a non-root username to QEMU as
> +argument. During initialization QEMU calls setuid and setgid with the
> +user ID and the group ID of the user passed as argument.
> +Libxl looks f
On 07/08/15 13:06, Wei Liu wrote:
>
-ctxt = xc_hypercall_buffer_alloc(dom->xch, ctxt, sizeof(*ctxt));
-if ( ctxt == NULL )
-return -1;
-
DOMPRINTF_CALLED(dom->xch);
/* misc stuff*/
@@ -259,13 +241,10 @@ int xc_dom_boot_image(struct
flight 60605 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60605/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail baseline untested
Tests which did not
On 07/08/15 11:17, Roger Pau Monne wrote:
> Place the calls to xc_vcpu_setcontext and the allocation of the hypercall
> buffer into the arch-specific vcpu hooks. This is needed for the next patch,
> so x86 HVM guests can initialize the BSP using XEN_DOMCTL_sethvmcontext
> instead of XEN_DOMCTL_setv
On 07/08/15 14:19, Ben Catterall wrote:
> On 06/08/15 20:52, Andrew Cooper wrote:
>> On 06/08/15 17:45, Ben Catterall wrote:
>>> The paging structure mappings for the deprivileged mode are added
>>> to the monitor page table for HVM guests. The entries are generated by
>>> walking the page tables a
On Fri, Aug 07, 2015 at 12:18:08PM +0200, Roger Pau Monne wrote:
> Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
> builder now uses the PV xc_dom_* set of functions this kernel will be parsed
> and loaded inside the guest like on PV, but the container is a pure HVM
>
On Thu, Aug 06, 2015 at 02:21:04PM +0800, 黄先生 wrote:
> hi all:
> My linux kernel verison is 2.6.32-15, and I make kernel with xen
> compileroptions. But when my virual machine start on AWS,it show these log:
> does anyone know how to do?
>
that is soo ancient I am sorry to say we can't hel
El 07/08/15 a les 16.54, Konrad Rzeszutek Wilk ha escrit:
> Ok. I hadn't run your patch yet. Do you want me to run the latest staging
> instead once more with my test-case?
Yes please, 40s in my test case seemed to be fine.
Roger.
___
Xen-devel mailin
On Tue, Aug 04, 2015 at 10:14:32AM +0200, Roger Pau Monné wrote:
> El 30/07/15 a les 10.53, Roger Pau Monné ha escrit:
> > El 28/07/15 a les 21.47, Konrad Rzeszutek Wilk ha escrit:
> >> Hey,
> >>
> >> I launch a bunch of guests at the same time or in parallel and
> >> the scripts end up timing out
On Fri, Aug 7, 2015 at 4:23 PM, Konrad Rzeszutek Wilk
wrote:
> Anyhow, your patch seems to fix a regression my patch
> feb44f1f7a4ac299d1ab1c3606860e70b9b89d69
> "x86/xen: Provide a "Xen PV" APIC driver to support >255 VCPUs"
> introduced.
Ahhh, good, okay. That explains why I didn't encounter th
On Thu, Aug 06, 2015 at 06:37:05PM +0200, Jason A. Donenfeld wrote:
> It turns out that domU also requires the Xen APIC driver. Otherwise we
> get stuck in busy loops that never exit, such as in this stack trace:
>
> (gdb) target remote localhost:
> Remote debugging using localhost:
> __xa
Hi Chris,
On 06/08/15 18:54, Chris (Christopher) Brand wrote:
> setup_frametable_mappings() rounds frametable_size up to a multiple
> of 32MB. This is wasteful on systems with less than 4GB of RAM,
> although it does allow the "contig" bit to be set in the PTEs.
>
> Where the frametable is less t
1 - 100 of 190 matches
Mail list logo
