The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
Switch to mfn_t in order to be more type safe.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durran
Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
xen/common/grant_table.c | 83 --
xen/incl
In case a system has memory above the 16TB boundary double the default
grant frame number limit per domain. This ensures a pv domain can still
establish the same number of grants even if it is required to use
version 2 grants which need twice the space of v1 grants.
Signed-off-by: Juergen Gross
R
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
V5:
-
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. Either do it from gnttab_setup_table() or just
before the domain is started the first time.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Dur
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. This will allow setting individual limits
in the future. For now initialize the per domain limits with the global
values.
Sig
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
---
V4:
- use domid_t (Wei Liu)
---
tools/libxc/include/xenctrl.h |
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
Reviewed-by: Paul Durrant
Acked-by: Wei Liu
---
V4:
- rename configuration items to use max_ prefixes (Wei Liu)
---
docs/man/xl.cfg.pod
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
flight 113130 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113130/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c50596a701435b62dc7e9c12b49201a17c38e17c
baseline version:
ovmf 89796c69d9fdaa9bd13d3
Hello~
I think this might be duplicate issue but, I have not resolved for long
time.
So, please understand this post generously.
First, I should explain my history.
1) I worked on the scheduler(credit scheduler) and I had a kernel panic by
my modification.
2) I tried to get any information for deb
flight 113140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113140/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On 08/09/17 05:40, John Thomson wrote:
> Hi,
> I get a PV domU kernel crash booting Arch Linux 4.12.
>
> Not sure if this is more relevant to Xen, the Linux kernel or
> distributions.
>
> Running xen-4.9.0 on Arch Linux x86_64 with kernel 4.12.10.
> Booting UEFI -> grub2 -> linux -> reboot -> gru
At a first glance it this appears to be an awesome proposal! I'll give
it a more thorough read over the weekend.
Thanks,
Roman.
On Thu, Sep 7, 2017 at 3:25 AM, Felipe Huici wrote:
> Dear all,
>
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’
flight 113138 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113138/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113122 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113122/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 113136 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113136/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113121 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Thu, 31 Aug 2017, George Dunlap wrote:
> +### Direct-boot kernel image format
> +
> +Supported, x86: bzImage
> +Supported, ARM32: zImage
> +Supported, ARM64: Image [XXX - Not sure if this is correct]
On ARM64 it's called Image.gz.
> +Format which the toolstack accept for direct-bo
On Wed, Aug 30, 2017 at 12:26:28PM +0200, Daniel Kiper wrote:
> On Tue, Aug 29, 2017 at 04:40:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > Since v1
> > [http://lists.gnu.org/archive/html/grub-devel/2017-08/msg00073.html]
> > - Fixed up patch with failing invocation,
> > - Redid patch #2 per Dani
flight 113135 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113135/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Thu, 31 Aug 2017, Jan Beulich wrote:
> >>> On 31.08.17 at 12:27, wrote:
> > vMCE: Is MCE an x86-only thing, or could this conceivably by extended
> > to ARM?
>
> I think this can't be reasonably extended beyond x86 (and,
> considering their similar origin, ia64).
Yes, Jan is right. ARM has SE
On Thu, 31 Aug 2017, Roger Pau Monne wrote:
> > +### ARM/Non-PCI device passthrough
> > +
> > +Status: Supported
>
> I guess non-pci devices on ARM also use the IOMMU? (SMMU)
Yes, they do.
> > +### ARM/SMMU
> > +
> > +Status: Supported, with caveats
> > +
> > +Only ARM SMMU hardware is
On Thu, 7 Sep 2017, Felipe Huici wrote:
> Dear all,
>
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
Only a couple of comments. I think this
Hi all,
I would be glad to sponsor this proposal. I think it will be of great
benefit to the ecosystem. Let me know if I need to do anything specific.
Cheers,
Stefano
On Thu, 7 Sep 2017, Lars Kurth wrote:
> Hi all,
>
> there is a technical issue which still needs resolving: we need a Sponsor.
flight 113133 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113133/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
Hey,
Some people asked me about Multiboot2 Specification and other GRUB doc stuff.
So, I have put latest things at
https://www.gnu.org/software/grub/grub-documentation.html
I hope that helps. If you have any questions please drop me a line.
Thanks,
Daniel
flight 113119 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113119/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 113117 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113117/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
This run is configured for baseline tests only.
flight 72072 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72072/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5
baseline v
On Wed, Aug 02, 2017 at 03:20:05AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 07/31/17 6:04 PM >>>
> >On Mon, Jul 31, 2017 at 07:55:34AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 07/26/17 9:50 PM >>>
> >> >--- a/docs/misc/livepatch.markdown
> >> >+++ b/docs/misc/livepatc
flight 113131 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113131/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Jo, 2017-09-07 at 17:12 +0100, Ian Jackson wrote:
> Petre Ovidiu PIRCALABU writes ("Re: [PATCH v10 1/3] gitignore: add
> local vimrc files"):
> >
> > On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > >
> > > OOI how does this work?
> ...
> >
> > I haven't added the file to the repository,
Hi,
On 05/09/17 18:15, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.
>
> Signed-off-by: Manish Jaggi
> ---
> xen/arch/arm/gic-v3-its.c| 23 +++
> xen/arch/arm/gic-v3.c| 1 +
Hi,
On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> This patch extends the gicv3_iomem_deny_access functionality by adding
> support for ITS region as well. Add function gicv3_its_deny_access.
>
> Signed-off-by: Manish Jaggi
> ---
> xen/arch/arm/gic-v3-its.c
Hi,
On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> estimate_acpi_efi_size needs to be updated to provide correct size of
> hardware domains MADT, which now adds ITS information as well.
>
> Introducing gic_get_hwdom_madt_size.
>
> Signed-off-by: Manish Jaggi
> --
Hi,
On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> Added gicv3_its_acpi_init to update host_its_list from MADT table.
> For ACPI, host_its structure stores dt_node as NULL.
>
> Signed-off-by: Manish Jaggi
> ---
> xen/arch/arm/gic-v3-its.c| 26 +++
Hi,
On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> add_to_host_its_list will update the host_its_list. This common
> function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_probe.
>
> Signed-off-by: Manish Jaggi
Makes sense.
Reviewed-by: Andre Przywara
Hey!
We wanted to brought up this small proposal regarding the lack of
parameterization on PV devices on Xen.
Currently users don't have a way for enforce and control what
features/queues/etc the backend provides. So far there's only global parameters
on backends, and specs do not mention anythin
map_domain_page_global() uses vmap under the hood, which works fine even
during very early boot. Relax the local_irq_is_enabled() part of the
assertion before Xen has finished booting.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/domain_page.c | 3 ++-
1 file
flight 113114 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113114/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Thank you for your replay even if this is quite late.
As you mention, I know there is an error (or some errors) but I cannot
guess where it is, so that I want to know where I should start debugging
from.
However, although I'm using serial console, I could get not enough clues
only from the kernel l
Petre Ovidiu PIRCALABU writes ("Re: [PATCH v10 1/3] gitignore: add local vimrc
files"):
> On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > OOI how does this work?
...
> I haven't added the file to the repository, just to .gitignore in order
> to mask it from git. It will help me very much to h
On Mon, Aug 14, 2017 at 03:28:50PM +0100, Roger Pau Monne wrote:
[...]
> +static void vpci_msix_control_write(struct pci_dev *pdev, unsigned int reg,
> +uint32_t val, void *data)
> +{
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT
>>> On 14.08.17 at 16:28, wrote:
> +void vpci_msix_arch_mask(struct vpci_arch_msix_entry *arch,
> + struct pci_dev *pdev, bool mask)
> +{
> +if ( arch->pirq == INVALID_PIRQ )
> +return;
How come no similar guard is needed in vpci_msi_arch_mask()?
> +int vpci_m
On Thu, Sep 07, 2017 at 01:36:36AM +0200, Dario Faggioli wrote:
> On Wed, 2017-09-06 at 12:29 -0700, Stefano Stabellini wrote:
> > On Wed, 6 Sep 2017, Dario Faggioli wrote:
> > >
> > > Or, in general, make sense out of the fact that the stack pointer
> > > register changes in such a way that, when
On Thu, Sep 07, 2017 at 03:36:00PM +, Petre Ovidiu PIRCALABU wrote:
> On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > OOI how does this work?
> >
> > You put a .vimrc under xen.git?
> I haven't added the file to the repository, just to .gitignore in order
> to mask it from git. It will hel
On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> OOI how does this work?
>
> You put a .vimrc under xen.git?
I haven't added the file to the repository, just to .gitignore in order
to mask it from git. It will help me very much to have it upstream
because right now I have to cherry-pick it each t
flight 113127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113127/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
>>> On 14.08.17 at 16:28, wrote:
> This is needed for MSI-X, since MSI-X will need to be initialized
> before parsing the BARs, so that the header BAR handlers are aware of
> the MSI-X related holes and make sure they are not mapped in order for
> the trap handlers to work properly.
>
> Signed-of
On Thu, Sep 07, 2017 at 03:59:05PM +0100, Wei Liu wrote:
> On Thu, Sep 07, 2017 at 03:56:16PM +0100, Roger Pau Monné wrote:
> > On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
[...]
> > > +/* Make sure the page has not been allocated */
> > > +if ( gfn_eq(iorp->gfn, IN
>>> On 14.08.17 at 16:28, wrote:
> +static unsigned int msi_flags(uint16_t data, uint64_t addr)
> +{
> +unsigned int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +rh = MASK_EXTR(addr, MSI_ADDR_REDIRECTION_MASK);
> +dm = MASK_EXTR(addr, MSI_ADDR_DESTMODE_MASK);
> +dest_id = MASK_EX
flight 113115 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113115/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5
baseline version:
ovmf b80a4097393c90d041b29
On Thu, Sep 07, 2017 at 12:04:21PM +0100, George Dunlap wrote:
> On 09/04/2017 02:44 PM, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Jan Beulich
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Stefano Stabellini
> > Cc: Tim
>>> On 07.09.17 at 16:51, wrote:
> On 07/09/17 16:41, Roger Pau Monné wrote:
>> On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
>>> A subsequent patch will remove the current implicit limitation on creation
>>> of ioreq servers which is due to the allocation of gfns for the ioreq
>>>
flight 113104 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
>>> On 07.09.17 at 16:26, wrote:
> After discussing with Andrew I'm willing to agree with the changes
> you do here, with one extra requirement: At least on non-debug
> builds X86EMUL_UNIMPLEMENTED should always result in #UD being
> raised by the final consumer of it. It should never, like would
On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
> ... XENMEM_resource_ioreq_server
>
> This patch adds support for a new resource type that can be mapped using
> the XENMEM_acquire_resource memory op.
>
> If an emulator makes use of this resource type then, instead of mapping
> gfns
On Thu, Sep 07, 2017 at 04:51:53PM +0200, Juergen Gross wrote:
> On 07/09/17 16:41, Roger Pau Monné wrote:
> > On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
> >> A subsequent patch will remove the current implicit limitation on creation
> >> of ioreq servers which is due to the allo
OOI how does this work?
You put a .vimrc under xen.git?
On Wed, Sep 06, 2017 at 04:48:24PM +0300, Petre Pircalabu wrote:
> Signed-off-by: Petre Pircalabu
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 594ffd9..8af9c02 100644
> --- a/
On Thu, Sep 07, 2017 at 03:56:16PM +0100, Roger Pau Monné wrote:
> On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
> > ... XENMEM_resource_ioreq_server
> >
> > This patch adds support for a new resource type that can be mapped using
> > the XENMEM_acquire_resource memory op.
> >
> >
flight 113110 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113110/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, Aug 21, 2017 at 04:12:27PM -0700, Stefano Stabellini wrote:
> Anthony,
>
> The code looks good. I tested this patch with Linux guests and seems to
> work OK, can you also confirm?
I've tested with Linux as well, an HVM guess, I did not spot any issue.
But, the code compiles with warnings
On Thu, Sep 07, 2017 at 02:52:49PM +0100, George Dunlap wrote:
> On 09/01/2017 04:00 PM, Wei Liu wrote:
> > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> >> +### Direct-boot kernel image format
> >> +
> >> +Supported, x86: bzImage
> >
> > Do you mean booting a PV guest? If s
On 07/09/17 16:41, Roger Pau Monné wrote:
> On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
>> A subsequent patch will remove the current implicit limitation on creation
>> of ioreq servers which is due to the allocation of gfns for the ioreq
>> structures and buffered ioreq ring.
>>
On Thu, Sep 07, 2017 at 02:39:57PM +0100, Andrew Cooper wrote:
> This resolves 11 Coverity issues along the lines of the following:
>
> 1600for ( i = 0; i < NR_RESERVED_GDT_PAGES; i++ )
>
> CID: Operands don't affect result
> (CONSTANT_EXPRESSION_RESULT)result_independent_of_opera
On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
>
> +mfn_t hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id,
> + unsigned int idx)
> +{
> +struct hvm_ioreq_server *s;
> +mfn_t mfn = INVALID_MFN;
> +
> +spin_lock_recursive(&d->arc
On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
> A subsequent patch will remove the current implicit limitation on creation
> of ioreq servers which is due to the allocation of gfns for the ioreq
> structures and buffered ioreq ring.
>
> It will therefore be necessary to introduce a
On 09/07/2017 02:57 PM, Roger Pau Monné wrote:
> On Thu, Sep 07, 2017 at 11:49:00AM +0100, George Dunlap wrote:
>> On 08/31/2017 12:25 PM, Roger Pau Monne wrote:
>>> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
[snip]
+### x86/PVH dom0
>>> ^ v2
+
+
On 06/09/17 14:48, Petre Pircalabu wrote:
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 64454c7..8a6eb74 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2044,6 +2044,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned
> long
>>> On 07.09.17 at 15:39, wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -121,8 +121,16 @@ typedef l4_pgentry_t root_pgentry_t;
> */
>
> /* Extract flags into 24-bit integer, or turn 24-bit flags into a pte mask.
> */
> -#define get_pte_flags(
Hi,
On 28/08/17 09:56, Bhupinder Thakur wrote:
> This patch fixes the issue observed when pl011 patches were tested on
> the junos hardware by Andre/Julien. It was observed that when large output is
> generated such as on running 'find /', output was getting truncated
> intermittently
> due to OU
On 09/07/2017 09:47 AM, Juergen Gross wrote:
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
Reviewed-by
On Thu, Sep 07, 2017 at 03:47:35PM +0200, Juergen Gross wrote:
> 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
> Reviewed-by: Paul Durrant
Acked-by: Wei Liu
_
On 09/07/2017 09:47 AM, Juergen Gross wrote:
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
Reviewed-by
>>> On 06.09.17 at 15:48, wrote:
> 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
>
On Thu, Sep 07, 2017 at 01:29:12PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 07 September 2017 13:16
> > To: Paul Durrant
> > Cc: Wei Liu ; xen-de...@lists.xenproject.org; Ian
> > Jackson ; Andrew Cooper
> > ; George Dunlap
>
On Thu, Sep 07, 2017 at 11:49:00AM +0100, George Dunlap wrote:
> On 08/31/2017 12:25 PM, Roger Pau Monne wrote:
> > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> >> +### x86/PV-on-HVM
> >
> > Do we really consider this a guest type? From both Xen and the
> > toolstack PoV this i
On 07/09/2017, 14:24, "Andrew Cooper" wrote:
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that bu
flight 113126 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113126/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On 09/01/2017 04:00 PM, Wei Liu wrote:
> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
>> +### Direct-boot kernel image format
>> +
>> +Supported, x86: bzImage
>
> Do you mean booting a PV guest? If so there are a few more formats.
>
>> +Supported, ARM32: zImage
>> +S
Hi all,
there is a technical issue which still needs resolving: we need a Sponsor. I am
thinking of Wei – he would qualify as a Hypervisor Leadership team member and
it would have the benefit of making sure that the MiniOS angle is covered. I
asked Wei, and he will get back to us once he read t
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. This will allow setting individual limits
in the future. For now initialize the per domain limits with the global
values.
Sig
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
Reviewed-by: Paul Durrant
---
V4:
- rename configuration items to use max_ prefixes (Wei Liu)
---
docs/man/xl.cfg.pod.5.in| 15 +
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
Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
xen/common/grant_table.c | 83 --
xen/incl
The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
Switch to mfn_t in order to be more type safe.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durran
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. Either do it from gnttab_setup_table() or just
before the domain is started the first time.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Dur
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
V3:
-
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
---
V4:
- use domid_t (Wei Liu)
---
tools/libxc/include/xenctrl.h |
In case a system has memory above the 16TB boundary double the default
grant frame number limit per domain. This ensures a pv domain can still
establish the same number of grants even if it is required to use
version 2 grants which need twice the space of v1 grants.
Signed-off-by: Juergen Gross
R
This resolves 11 Coverity issues along the lines of the following:
1600for ( i = 0; i < NR_RESERVED_GDT_PAGES; i++ )
CID: Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)result_independent_of_operands: ((33U /* 1U |
0x20U */) | (({...}) ? 8388608U /* 1U << 23 */ : 0)
On 07/09/17 11:25, Felipe Huici wrote:
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to
Hello Olensandr,
I able to boot xen and trying to boot dom0 but there are no console log for
dom0.
following log for xen and it stuck booting dom0.
(XEN) I/O virtualisation disabled
(XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
(XEN) alternatives: Patching with alt table 400d2
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 September 2017 13:16
> To: Paul Durrant
> Cc: Wei Liu ; xen-de...@lists.xenproject.org; Ian
> Jackson ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.o
I have installed Xen 4.8.0 on an Ubuntu PC and I was able to get audio in
Domain U using PCI passthrough by hot-plugging the audio device controller
to Domain U using xl and loading the corresponding PCI frontend and backend
modules[https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough].
I wish to
On Thu, Sep 07, 2017 at 01:03:46PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 07 September 2017 13:00
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> > Wei Liu ; Andrew Cooper
> > ; George Dunlap
>
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 September 2017 13:00
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> Wei Liu ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.o
On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> A subsequent patch will introduce a new scheme to allow an emulator to
> map ioreq server pages directly from Xen rather than the guest P2M.
>
> This patch lays the groundwork for that change by deferring mapping of
> gfns until their
>>> On 07.09.17 at 13:36, wrote:
> On Thu, Sep 07, 2017 at 12:18:25PM +0100, Paul Durrant wrote:
>> Ok, if you think it's necessary. (This is a tools-only hypercall and the
> ranges are supplied by privcmd, allocated in kernel).
>
> IMHO we should allow for use case for semi-trusted users of thi
1 - 100 of 183 matches
Mail list logo
