On Wed, Nov 14, 2018 at 10:37:42AM +, Sergey Dyasli wrote:
> Signed-off-by: Sergey Dyasli
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Nov 09, 2018 at 08:14:57PM +0100, Daniel Kiper wrote:
> On Fri, Nov 02, 2018 at 01:37:31PM +0100, Juergen Gross wrote:
> > Add possible PCI space MMIO areas as "Reserved" to the memory map in
> > order to avoid using those areas for special Xen pages later.
> >
> > Signed-off-by: Juergen
On Fri, Nov 02, 2018 at 01:37:30PM +0100, Juergen Gross wrote:
> Retrieve the memory map from the hypervisor and normalize it to contain
> no overlapping entries and to be sorted by address.
>
> Signed-off-by: Juergen Gross
> ---
> V3: use grub_e820_mmap_entry instead of own struct (Daniel
grub_xen_panic (Roger Pau Monné)
> issue panic message (Roger Pau Monné)
> rewrite grub_xen_hypercall to avoid register variables (Daniel Kiper)
> ---
> grub-core/kern/i386/xen/pvh.c | 69
> +++
> 1 file changed, 69 insertions(+)
&g
e not behind an IOMMU, and conceptually it's also wrong
> > to give the hardware domain ownership of those devices since they are
> > in use by Xen.
> >
> > Fix this by assigning the PCI IOMMU devices to Xen.
> >
> > Signed-off-by: Roger Pau Monné
>
>
Write back the possibly modified memory map to the hypervisor in case
> the guest is reading it from there again.
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross
> ---
> V4: write back memory map
On Fri, Nov 02, 2018 at 01:37:33PM +0100, Juergen Gross wrote:
> Add all usable memory regions to grub memory management and add the
> needed mmap iterate code, which will be used by grub core (e.g.
> grub-core/lib/relocator.c or grub-core/mmap/mmap.c).
>
> As we are running in 32-bit mode don't
On Thu, Nov 15, 2018 at 09:10:26AM +0800, Chao Gao wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback. Someone reported this
On Thu, Nov 08, 2018 at 09:25:26AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 14:20, wrote:
> > On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 13:47, wrote:
> >> > My point would be that on x86 I think the only way to have preemptible
> >> > long-running
On Mon, Sep 24, 2018 at 11:55:29AM +0100, Andrew Cooper wrote:
> In practice, this allows the compiler to replace the loop with a pair of movs.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
__
On Mon, Sep 24, 2018 at 11:55:30AM +0100, Andrew Cooper wrote:
> It is MASK_EXTR() in disguise, but less flexible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing
o.
Reviewed-by: Roger Pau Monné
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, Oct 09, 2018 at 12:22:34PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 09 October 2018 11:42
> > To: xen-devel@lists.xenproject.org
> > Cc: Jan Beulich ; Roger Pau Monne
> > ; Paul Durrant ; Wei Liu
> > ; Kevin Tian
>
even in that
case the current code is wrong).
Instead move the code that performs the mapping/unmapping to
a tasklet and pause the guest vCPU until the {un}mapping is done and
the memory decoding bit has been toggled.
Signed-off-by: Roger Pau Monné
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc:
On Wed, Oct 10, 2018 at 09:59:21AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Wei Liu
> > Sent: 09 October 2018 19:58
> > To: xen-devel@lists.xenproject.org
> > Cc: Wei Liu ; Jan Beulich ; Roger
> >
On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
> Hi Roger,
>
> Sorry for the late reply.
>
> On 09/03/2018 03:40 PM, Roger Pau Monné wrote:
> > On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote:
> > > On 03/0
On Wed, Sep 26, 2018 at 11:32:38AM +0100, Julien Grall wrote:
> Hi,
>
> On 09/26/2018 10:14 AM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > Sent: 26 September 2018 09:09
> > > To: Julien Grall ; Paul Durrant
> > >
> > > Cc: Andrew
D.
>
> Move the default setting of iommu_hwdom_{inclusive/reserved} to
> arch_iommu_hwdom_init since the defaults are now the same for both
> Intel and AMD.
>
> Reported-by: Paul Durrant
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Suravee Suthikulpanit
> Cc: Brian
On Wed, Sep 26, 2018 at 01:29:27PM +0100, Andrew Cooper wrote:
> On 08/06/18 10:59, Roger Pau Monne wrote:
> > @@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
> > if ( dom->start_info_seg.pfn )
> > bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
> >
>
ould always be
> false.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
This is fine (and will fix destroying HVM/PVH guests), but I would
still like deallocate_iommu_page_tables (from pci_amd_iommu.c) to be
fixed in order to avoid the usage of iommu_use_hap_pt there al
On Mon, Oct 01, 2018 at 04:33:45PM +0100, Julien Grall wrote:
> Hi,
>
> On 10/01/2018 04:27 PM, Roger Pau Monné wrote:
> > On Tue, Sep 25, 2018 at 08:36:36PM +0100, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > Sorry for the late reply.
> >
p compatibility with toolstack creating Arm guest with PV type
> (e.g libvirt), libxl will now convert those guests to PVH.
>
> Furthermore, the default type for Arm in xl will now be PVH to allow
> smooth transition for user.
>
> Signed-off-by: Julien Gra
On Mon, Sep 24, 2018 at 02:28:26PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 09/12/2018 11:29 AM, Roger Pau Monné wrote:
> > On Wed, Sep 12, 2018 at 10:48:42AM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 09/12/2018 10:16 AM, Roger Pau Monné
appings code between Intel and AMD. Note that reserved
regions above 4GB will still be mapped.
> > Move the default setting of iommu_hwdom_{inclusive/reserved} to
> > arch_iommu_hwdom_init since the defaults are now the same for both
> > Intel and AMD.
> >
> > Reported-by:
On Mon, Oct 01, 2018 at 07:57:19PM +0100, Julien Grall wrote:
> The PV fields kernel, ramdisk, cmdline are only there for compatibility
> with old toolstack. Instead of manually copying them over to there new
> field, use the deprecated_by attribute in the IDL.
>
> Suggested-by:
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pau Monné
>
> This is all moderately nasty, but that is entirely the fault of get/set
> context API. Seeing as the interface is going to be fully rewritten
> eventually, this will do.
>
> > ---
>
On Mon, Aug 27, 2018 at 03:46:03AM -0600, Jan Beulich wrote:
> >>> On 22.08.18 at 12:36, wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/configs/pvshim_defconfig
> > @@ -0,0 +1,23 @@
> > +# Enable PV shim mode
> > +CONFIG_PV=y
> > +CONFIG_XEN_GUEST=y
> > +CONFIG_PVH_GUEST=y
> > +CONFIG_PV_SHIM=y
On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote:
> On 03/09/18 12:09, Julien Grall wrote:
> >
> >
> > On 23/08/18 08:58, Roger Pau Monné wrote:
> > > On Wed, Aug 22, 2018 at 06:48:05PM +0100, Julien Grall wrote:
> > > > >
On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
> >>> On 24.08.18 at 11:58, wrote:
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/hvmloader.lds
> > @@ -0,0 +1,13 @@
> > +SECTIONS
> > +{
> > + . = 0x10;
> > + /*
> > + * NB: there's no need to use the AT keyword in order
la Alexandru wrote:
> > > >
> > > > On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
> > > > >
> > > > > If you look at vcpu_hvm in tools/libxc/xc_dom_x86.c it saves
> > > > > the
> > > > > full
>
On Mon, Sep 17, 2018 at 12:05:26PM +0200, Andreas Kinzler wrote:
> Hello Roger,
>
> > > Some weeks ago I tried a quite new version of Xen 4.10.2-pre
> > > (http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=a645331a9f4190e92ccf41a950bc4692f8904239)
> > > and the PCI card (LSI SAS HBA) using
On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
> Hello,
>
> While doing my best to make sure what I understand to be George's
> proposed changes for the altp2m series I've tried to boot Xen staging on
> an AMD host, but it crashes in an unrelated place (I've tested this by
>
On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 12:48, wrote:
> > On 9/21/18 1:41 PM, Jan Beulich wrote:
> > On 21.09.18 at 12:15, wrote:
> >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
> While doing my best to make sure what I
On Fri, Sep 21, 2018 at 01:05:42PM +0200, Roger Pau Monné wrote:
> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
> > >>> On 21.09.18 at 12:48, wrote:
> > > On 9/21/18 1:41 PM, Jan Beulich wrote:
> > >>>>> On 21.09.18 at 12:15, w
On Fri, Sep 21, 2018 at 06:04:31AM -0600, Jan Beulich wrote:
> >>> On 21.09.18 at 12:59, wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -465,7 +465,7 @@ unsigned int page_get_ram_type(mfn_t mfn)
> > break;
> >
> > default:
> > -
On Fri, Nov 16, 2018 at 10:06:36AM +, Alexandru Stefan ISAILA wrote:
> A new mechanism has been added which is able to generically re-execute
> instructions, by temporarily granting permissions inside the EPT and
> re-executing the instruction with all other vcpus paused and with the
> monitor
On Fri, Nov 16, 2018 at 05:11:39AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > Current logic to handle long running operations has two flaws:
> >
> > - hvm_io_pending is only used by Intel code, fix this by moving the
> >call to vpci_process_pending into
On Wed, Dec 26, 2018 at 07:42:14PM +0800, Pu Wen wrote:
> On 2018/12/21 18:20, Andrew Cooper wrote:
> >> + /* Hygon CPUs do not support SYSENTER outside of legacy mode. */
> >> + __clear_bit(X86_FEATURE_SEP, c->x86_capability);
> >> +
> >> + /* Hygon processors have APIC timer running in deep C
On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
> to already wake up the kernel thread.
>
> Signed-off-by: Dongli Zhang
Reviewed-by: Roger Pau Monné
kthread_stop waits for the thread to exit
;
> Rewrite the command line documentation almost from scratch, including
> far more detail.
>
> Signed-off-by: Andrew Cooper
Thanks for doing this:
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC:
catch-all.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> diff --git a/xen/drivers/passthrough/x86/iommu.c
> b/xen/drivers/passthrough/x86/iommu.c
> index e40d7a7..9fe2329 100644
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passth
On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
> to already wake up the kernel thread.
>
> Signed-off-by: Dongli Zhang
> ---
> drivers/block/xen-blkback/xenbus.c | 4 +---
> 1 file changed, 1
ip the IOMMU requirement.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Juergen Gross
>
> v2:
> * Retain `none` as opposed
On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> > > From: Simon Gaiser
> > >
> &g
mode. Hide both options behind the relevent
> CONFIG_* settings, and default to PVH mode when CONFIG_PV is compiled
> out.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Juergen
On Wed, Jan 16, 2019 at 07:59:44PM +0800, Chao Gao wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> >> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> >
On Wed, Jan 16, 2019 at 05:57:04AM -0700, Jan Beulich wrote:
> >>> On 16.01.19 at 13:20, wrote:
> > Do you think it makes sense to add a domctl to enable/disable MSI(X)?
>
> A domctl looks odd for an operation like this; I'd rather consider
> adding a physdevop if a new (sub)hypercall is needed
On Wed, Jan 16, 2019 at 09:00:46AM +, Andrew Cooper wrote:
> Alter parse_pci_param() to use parse_boolean(), so the sub options
> behave like other Xen booleans.
>
> Update the command line documentation for consistency.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
On Tue, Jan 15, 2019 at 03:49:07AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 11:27, wrote:
> > On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
> >> >>> On 15.01.19 at 10:44, wrote:
> >> >> -Original Message-
> >> > [snip]
> >> >> >> (XEN) Xen call trace:
> >> >> >>
On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 10:44, wrote:
> >> -Original Message-
> > [snip]
> >> >> (XEN) Xen call trace:
> >> >> (XEN)[] iommu_map+0xba/0x176
> >> >> (XEN)[] iommu_hwdom_init+0xef/0x220
> >> >> (XEN)[]
On Tue, Jan 15, 2019 at 01:27:39AM -0800, Christopher Clark wrote:
> The register op is used by a domain to register a region of memory for
> receiving messages from either a specified other domain, or, if specifying a
> wildcard, any domain.
>
> This operation creates a mapping within Xen's
On Tue, Jan 15, 2019 at 01:27:36AM -0800, Christopher Clark wrote:
> Initialises basic data structures and performs teardown of argo state
> for domain shutdown.
>
> Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
>
> Introduces a new Xen command line parameter 'argo': bool to
On Tue, Jan 15, 2019 at 05:42:16AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 13:29, wrote:
> > On Tue, Jan 15, 2019 at 01:27:36AM -0800, Christopher Clark wrote:
> >> long
> >> do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> >> XEN_GUEST_HANDLE_PARAM(void)
On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback is used only in PV domains.
You still need pciback in order to reset the device when it's
deassigned from the
On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
> On 16.01.19 at 10:00, wrote:
> >> --- a/docs/misc/xen-command-line.pandoc
> >> +++ b/docs/misc/xen-command-line.pandoc
> >> @@ -636,61 +636,83 @@ trace feature is only enabled in
On Wed, Jan 16, 2019 at 02:49:14PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 01:20:04PM +0100, Roger Pau Monné wrote:
> > On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Rog
On Wed, Jan 16, 2019 at 06:00:33PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 05:47:19PM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> > > HVM domains use IOMMU and device model assistance
On Thu, Jan 17, 2019 at 10:10:00AM +0800, Dongli Zhang wrote:
> Hi Roger,
>
> On 2019/1/16 下午10:52, Roger Pau Monné wrote:
> > On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> >> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
On Wed, Jan 16, 2019 at 10:48:52PM -0800, Christopher Clark wrote:
> On Tue, Jan 15, 2019 at 7:49 AM Roger Pau Monné wrote:
> >
> > On Tue, Jan 15, 2019 at 01:27:41AM -0800, Christopher Clark wrote:
> > > sendv operation is invoked to perform a synchronous send of buffers
On Tue, Jan 15, 2019 at 04:36:30PM +0100, Marek Marczykowski-Górecki wrote:
> Stubdomain do not have it's own config file - its configuration is
> derived from target domains. Do not try to manipulate it when attaching
> PCI device.
>
> This bug prevented starting HVM with stubdomain and PCI
On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
> On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné wrote:
> >
> > On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
> > > diff --git a/xen/include/public/argo.h b/xen/include/public/ar
On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
> >>> On 17.01.19 at 09:57, wrote:
> > While not against using physdevop if we agree that a new hypercall is
> > the way to go, I would prefer a domctl because this hypercall would
> > only be used by toolstack components, and thus
On Tue, Jan 15, 2019 at 04:36:29PM +0100, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, handling "pci-ins" command will fail
> if pcifront is not initialized already. Fix this by sending such command
> only after confirming that pciback/front is running.
>
>
On Thu, Jan 17, 2019 at 01:44:32PM -0800, Christopher Clark wrote:
> On Thu, Jan 17, 2019 at 3:12 AM Roger Pau Monné wrote:
> >
> > On Wed, Jan 16, 2019 at 10:54:48PM -0800, Christopher Clark wrote:
> > > On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné
> > > w
On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenboom wrote:
> Hi Roger,
>
> I gave PVH dom0 a spin, see how far I would get.
Thanks!
> With current xen-unstable unfortunately not that far, i got the splat below.
Yes, this was already reported:
On Fri, Jan 18, 2019 at 03:17:57PM +0100, Sander Eikelenboom wrote:
> On 18/01/2019 13:50, Roger Pau Monné wrote:
> > On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenboom wrote:
> >> Hi Roger,
> >>
> >> I gave PVH dom0 a spin, see
On Fri, Jan 18, 2019 at 03:54:14PM -0800, Christopher Clark wrote:
> On Fri, Jan 18, 2019 at 1:44 AM Roger Pau Monné wrote:
> >
> > On Thu, Jan 17, 2019 at 01:44:32PM -0800, Christopher Clark wrote:
> > > On Thu, Jan 17, 2019 at 3:12 AM Roger Pau Monné
> > > w
On Tue, Jan 15, 2019 at 01:27:32AM -0800, Christopher Clark wrote:
> Version four of this patch series.
>
> * Changes are primarily addressing feedback from the v3 series reviews.
> Many points noted on the invididual commit posts.
>
> * Register ring interfaces uses Xen gfns as page
On Tue, Jan 15, 2019 at 03:24:31PM +, Andrew Cooper wrote:
> On 30/11/2018 09:01, Chao Gao wrote:
> > On Thu, Nov 29, 2018 at 10:56:53AM +0100, Roger Pau Monné wrote:
> >> On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
> >>> On Wed, Nov 28, 2018 at 04:
On Tue, Jan 15, 2019 at 09:10:41AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 16:49, wrote:
> > On Tue, Jan 15, 2019 at 01:27:41AM -0800, Christopher Clark wrote:
> >> +static int
> >> +pending_requeue(const struct domain *d, struct argo_ring_info *ring_info,
> >> +domid_t
On Tue, Jan 15, 2019 at 01:27:41AM -0800, Christopher Clark wrote:
> sendv operation is invoked to perform a synchronous send of buffers
> contained in iovs to a remote domain's registered ring.
>
> It takes:
> * A destination address (domid, port) for the ring to send to.
>It performs a
On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
> Queries for data about space availability in registered rings and
> causes notification to be sent when space has become available.
>
> The hypercall op populates a supplied data structure with information about
> ring state,
On Tue, Jan 15, 2019 at 01:27:40AM -0800, Christopher Clark wrote:
> Takes a single argument: a handle to the ring unregistration struct,
> which specifies the port and partner domain id or wildcard.
>
> The ring's entry is removed from the hashtable of registered rings;
> any entries for pending
On Mon, Jan 14, 2019 at 3:48 PM Wei Liu wrote:
>
> Hi all
>
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still need to be addressed). Frankly
> I don't think there is enough time to address all the technical details,
> but let me
On Sun, Jan 20, 2019 at 05:59:36PM -0800, Christopher Clark wrote:
> On Sat, Jan 19, 2019 at 4:06 AM Roger Pau Monné wrote:
> >
> > On Fri, Jan 18, 2019 at 03:54:14PM -0800, Christopher Clark wrote:
> > > On Fri, Jan 18, 2019 at 1:44 AM Roger Pau Monné
> > > w
se in this series (which is based on [1]).
>
> Signed-off-by: Christopher Clark
> Acked-by: Lars Kurth
> Reviewed-by: Ross Philipson
Thanks.
Reviewed-by: Roger Pau Monné
I've got some nits below, but it's purely cosmetic changes to make the
code cleaner.
> ---
> v4 Jan: amen
On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> >> +}
> >> +}
> >> +/*
> >> + * All pirq-
On Mon, Jan 21, 2019 at 01:59:47AM -0800, Christopher Clark wrote:
> The register op is used by a domain to register a region of memory for
> receiving messages from either a specified other domain, or, if specifying a
> wildcard, any domain.
>
> This operation creates a mapping within Xen's
t;
> Signed-off-by: Andrew Cooper
> Release-acked-by: Juergen Gross
Reviewed-by: Roger Pau Monné
Will it be worth printing a warning message in arch_iommu_hwdom_init
about map-inclusive deprecation if it's enabled?
Thanks, Roger.
___
Xen-deve
On Tue, Jan 22, 2019 at 10:43:11AM +0100, nicolas.poi...@bertin.fr wrote:
> Hi everyone,
>
> I was wondering why when I build an x86_64 xen I got a mkelf32 command
> converting elf 64 to elf 32.
> My understanding, looking at git-log, is that that was needed for 32bits
> bootloaders.
>
> Is
niov */
> +/* arg4 is message_type. Must be a 32-bit value. */
> +
> +rc = copy_from_guest(_addr, send_addr_hnd, 1) ? -EFAULT : 0;
> +if ( rc )
> +break;
> +
> +/*
> + * Check padding is zeroed. Reject niov above limit or message_types
> + * that are outside 32 bit range.
> + */
> +if ( unlikely(send_addr.src.pad || send_addr.dst.pad ||
> + (arg3 > XEN_ARGO_MAXIOV) || (arg4 & ~0xUL)) )
arg4 & (GB(4) - 1)
Is clearer IMO, or:
arg4 > UINT32_MAX
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +if ( send_addr.src.domain_id == XEN_ARGO_DOMID_ANY )
> +send_addr.src.domain_id = currd->domain_id;
> +
> +/* No domain is currently authorized to send on behalf of another */
> +if ( unlikely(send_addr.src.domain_id != currd->domain_id) )
> +{
> +rc = -EPERM;
> +break;
> +}
> +
> +/*
> + * Check access to the whole array here so we can use the faster
> __copy
> + * operations to read each element later.
> + */
> +if ( unlikely(!guest_handle_okay(iovs_hnd, arg3)) )
You need to set rc to EFAULT here, because the call to copy_from_guest
has set it to 0.
Alternatively you can change the call above to be:
if ( copy_from_guest(_addr, send_addr_hnd, 1) )
return -EFAULT;
So rc doesn't get set to 0 on success.
With those taken care of:
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
d_info hash table.
>
> Signed-off-by: Christopher Clark
LGTM:
Reviewed-by: Roger Pau Monné
Just one nit about the open-coded list_for_each.
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index a7ec0e0..e4cd446 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/ar
k
LGTM, but I would like to see the open-coded versions of the list_
macros fixed:
Reviewed-by: Roger Pau Monné
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index 518aff7..4b43bdd 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
[...]
> +static void
&g
On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote:
> Version five of this patch series:
>
> * Changes are primarily addressing feedback from the v4 series reviews.
> Many points noted on the invididual commit posts.
>
> * Critical sections have been shrunk, with allocations and
On Wed, Jan 23, 2019 at 12:39:21AM +0100, Sander Eikelenboom wrote:
> On 22/01/2019 17:14, Roger Pau Monné wrote:
> > On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
> >> On 18/01/2019 18:56, Roger Pau Monné wrote:
> >>> On Fri, Jan 18, 20
On Thu, Jan 17, 2019 at 05:20:18AM -0700, Jan Beulich wrote:
> >>> On 17.01.19 at 12:56, wrote:
> > On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
> >> >>> On 17.01.19 at 09:57, wrote:
> >> > While not against using physdevop if we agree that a new hypercall is
> >> > the way to
On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback. Someone reported this
ion. Also drop the individual
> documentation for deprecated options which refer to their newer
> versions, for the same reason.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Just one comment.
[...]
> +* The `map-inclusive` boolean is applicable to x86 PV dom0's, and
On Thu, Jan 17, 2019 at 06:32:01AM -0700, Jan Beulich wrote:
> >>> On 16.01.19 at 10:00, wrote:
> > This option is unique to x86 PV dom0's, but it is not sensible to have a
> > catch-all which blindly maps all non-RAM regions into the IOMMU.
> >
> > The map-reserved option remains, and covers
On Mon, Jan 14, 2019 at 10:53:54PM -0800, Christopher Clark wrote:
> On Thu, Jan 10, 2019 at 4:22 AM Roger Pau Monné wrote:
> >
> > On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> > > +
> > > +argo_dprintk("fill_ring
gt; xen_blkif_disconnect() when frontend is destroyed.
>
> This patch reworks connect_ring() to read xenstore 'ring-page-order' only
> once.
>
> Signed-off-by: Dongli Zhang
LGTM:
Reviewed-by: Roger Pau Monné
Thanks!
___
Xen-
On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> From: Simon Gaiser
>
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in
On Fri, Nov 30, 2018 at 05:32:52PM -0800, Christopher Clark wrote:
> Used by a domain to register a region of memory for receiving messages from
> either a specified other domain, or, if specifying a wildcard, any domain.
>
> This operation creates a mapping within Xen's private address space
On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 16:56, wrote:
> > On Wed, Dec 12, 2018 at 03:32:53AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 11:04, wrote:
> >> > You mentioned there's some code (for PV?) to calculate the size of the
> >> > page tables
On Wed, Dec 12, 2018 at 03:32:53AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 11:04, wrote:
> > On Wed, Dec 12, 2018 at 02:53:26AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 10:14, wrote:
> >> > On Tue, Dec 11, 2018 at 08:33:08AM -0700, Jan Beulich wrote:
> >> >> >>> On 11.12.18 at
On Fri, Nov 30, 2018 at 05:32:46PM -0800, Christopher Clark wrote:
> Applied to both x86 and ARM headers.
>
> Signed-off-by: Christopher Clark
> ---
> xen/include/asm-arm/guest_access.h | 25 +
> xen/include/asm-x86/guest_access.h | 29 +
>
On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:54, wrote:
> > To note it's calculating the approximate amount of memory required by
> > shadow paging.
>
> I don't understand this logic, and ...
>
> > @@ -325,7 +325,7 @@ unsigned long __init
On Tue, Dec 11, 2018 at 08:19:34AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:55, wrote:
> > +unsigned long __init dom0_hap_pages(const struct domain *d,
> > +unsigned long nr_pages)
> > +{
> > +/*
> > + * Attempt to account for at least some of
On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index 66f2474..b63249e 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -52,4 +52,10 @@ void
t; Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
901 - 1000 of 5756 matches
Mail list logo
