On 26.07.2021 17:45, Julien Grall wrote:
> On 23/07/2021 14:02, Jan Beulich wrote:
>> On 23.07.2021 11:28, Julien Grall wrote:
>>> On 23/07/2021 07:31, Jan Beulich wrote:
On 23.07.2021 01:36, Stefano Stabellini wrote:
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/pa
On 27.07.2021 14:33, Andrew Cooper wrote:
> On 22/07/2021 10:20, Jan Beulich wrote:
>> I suspect it is commit 40726f16a8d7 ("ld script expression parsing")
>> which broke the hypervisor build, by no longer accepting section names
>> with a dash in them inside ADDR() (and perhaps other script direct
flight 164085 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 164084 qemu-mainline real [real]
flight 164087 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164084/
http://logs.test-lab.xenproject.org/osstest/logs/164087/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
From: Brian Woods
For the legacy path, arm_smmu_dt_add_device_legacy is called by
register_smmu_master scanning mmu-masters (a fwspec entry is also
created.) For the generic path, arm_smmu_dt_add_device_generic gets
called instead. Then, arm_smmu_dt_add_device_generic calls
arm_smmu_dt_add_device
From: Brian Woods
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. This will allow for using
current Linux device trees with just modifying the chosen field to
enable Xen.
Signed-off-by: Brian Woods
Signed-off-by: Stefano Stabellini
iommu_add_dt_device() returns -EEXIST if the device was already
registered. At the moment, this can only happen if the device was
already assigned to a domain (either dom0 at boot or via
XEN_DOMCTL_assign_device).
In a follow-up patch, we will convert the SMMU driver to use the FW
spec. When the l
From: Brian Woods
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.
Signed-off-by: Brian Woods
Signed-off-by:
Hi all,
This series introduces support for the generic SMMU bindings to
xen/drivers/passthrough/arm/smmu.c.
Cheers,
Stefano
Brian Woods (3):
arm,smmu: switch to using iommu_fwspec functions
arm,smmu: restructure code in preparation to new bindings support
arm,smmu: add support
On Mon, 2 Aug 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 30/07/2021 22:57, Stefano Stabellini wrote:
> > On Mon, 26 Jul 2021, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 23/07/2021 21:16, Stefano Stabellini wrote:
> > > > On Fri, 23 Jul 2021, Julien Grall wrote:
> > > > > > Signed-of
flight 164083 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi,
On 02/08/2021 15:06, Oleksandr Andrushchenko wrote:
On 30.07.21 13:38, Juergen Gross wrote:
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate o
Hi Stefano,
Thank you for the comments and ideas.
On 31.07.21 02:57, Stefano Stabellini wrote:
On Fri, 30 Jul 2021, Oleksandr wrote:
Hi Andrew, Julien.
@Andrew, I think that arguments you provided in your first answer (why the
proposed solution is a potentially racy and not a safe) are v
flight 164082 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164082/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164073
test-armhf-armhf-libvirt 16 sav
Hi all,
For those I have not yet met, I'm Ashley Weltz a Project Coordinator from
The Linux Foundation stepping in to support Xen. I joined last month's
community call, and I will be taking over for George while he is out.
Please let me know if you have any questions. I look forward to working
wit
Hi Stefano,
On 30/07/2021 22:57, Stefano Stabellini wrote:
On Mon, 26 Jul 2021, Julien Grall wrote:
Hi Stefano,
On 23/07/2021 21:16, Stefano Stabellini wrote:
On Fri, 23 Jul 2021, Julien Grall wrote:
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- new patch
---
xen/drivers/passth
Hello Jeremy Fitzhardinge,
The patch 4bac07c993d0: "xen: add the Xenbus sysfs and virtual device
hotplug driver" from Jul 17, 2007, leads to the following static
checker warning:
drivers/xen/xenbus/xenbus_xs.c:125 xs_request_enter()
warn: sleeping in atomic context
drivers/xen/xe
On 8/2/2021 9:20 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 10:52:28AM -0400, Tianyu Lan wrote:
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
storvsc rx/tx ring buffer. The page buffer used by vmbus_sen
Hi, Juergen!
On 30.07.21 13:38, Juergen Gross wrote:
> In order to avoid problems in case the backend is modifying a response
> on the ring page while the frontend has already seen it, just read the
> response into a local buffer in one go and then operate on that buffer
> only.
>
> Signed-off-by:
flight 164079 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 8/2/2021 8:39 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 10:52:21AM -0400, Tianyu Lan wrote:
+ hv_ghcb->ghcb.protocol_version = 1;
+ hv_ghcb->ghcb.ghcb_usage = 1;
The values set to ghcb_usage deserve some defines (here and below).
OK. Will update in the next version.
On Mon, Aug 02, 2021 at 03:11:40PM +0200, Juergen Gross wrote:
> As those cases are all mutually exclusive, wouldn't a static_call() be
> the appropriate solution?
Right, static_call() is even better, thanks.
On Wed, Jul 28, 2021 at 10:52:28AM -0400, Tianyu Lan wrote:
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> mpb_desc() still need to ha
On 8/2/2021 8:28 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 10:52:20AM -0400, Tianyu Lan wrote:
+void hv_ghcb_msr_write(u64 msr, u64 value)
+{
+ union hv_ghcb *hv_ghcb;
+ void **ghcb_base;
+ unsigned long flags;
+
+ if (!ms_hyperv.ghcb_base)
+ return;
+
On 02.08.21 14:01, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 08:29:41AM -0700, Dave Hansen wrote:
__set_memory_enc_dec() is turning into a real mess. SEV, TDX and now
Hyper-V are messing around in here.
I was going to suggest a PV_OPS call where the fitting implementation
for the guest envi
On 8/2/2021 8:59 PM, Joerg Roedel wrote:
On Mon, Aug 02, 2021 at 08:56:29PM +0800, Tianyu Lan wrote:
Both second and third are HV_GPADL_RING type. One is send ring and the
other is receive ring. The driver keeps the order to allocate rx and
tx buffer. You are right this is not robust and will ad
On 7/31/21 8:08 AM, Uwe Kleine-König wrote:
> Hello Boris,
>
> On Fri, Jul 30, 2021 at 04:37:31PM -0400, Boris Ostrovsky wrote:
>> On 7/29/21 4:37 PM, Uwe Kleine-König wrote:
>>> --- a/drivers/pci/xen-pcifront.c
>>> +++ b/drivers/pci/xen-pcifront.c
>>> @@ -599,12 +599,12 @@ static pci_ers_result_
flight 164081 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164081/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 03e77558d4939b9c21e94f03072360e9b00bb559
baseline version:
ovmf 3445058aea4f64a994e4e
On 8/2/2021 8:01 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 08:29:41AM -0700, Dave Hansen wrote:
__set_memory_enc_dec() is turning into a real mess. SEV, TDX and now
Hyper-V are messing around in here.
I was going to suggest a PV_OPS call where the fitting implementation
for the guest
On Mon, Aug 02, 2021 at 08:56:29PM +0800, Tianyu Lan wrote:
> Both second and third are HV_GPADL_RING type. One is send ring and the
> other is receive ring. The driver keeps the order to allocate rx and
> tx buffer. You are right this is not robust and will add a mutex to keep
> the order.
Or you
On Wed, Jul 28, 2021 at 10:52:22AM -0400, Tianyu Lan wrote:
> + if (hv_is_isolation_supported()) {
> + vmbus_connection.monitor_pages_va[0]
> + = vmbus_connection.monitor_pages[0];
> + vmbus_connection.monitor_pages[0]
> + = memrem
On 8/2/2021 8:07 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 10:52:19AM -0400, Tianyu Lan wrote:
+ if (type == HV_GPADL_BUFFER)
+ index = 0;
+ else
+ index = channel->gpadl_range[1].gpadlhandle ? 2 : 1;
Hmm... This doesn't look very robust. Can yo
On Wed, Jul 28, 2021 at 10:52:21AM -0400, Tianyu Lan wrote:
> + hv_ghcb->ghcb.protocol_version = 1;
> + hv_ghcb->ghcb.ghcb_usage = 1;
The values set to ghcb_usage deserve some defines (here and below).
> +
> + hv_ghcb->hypercall.outputgpa = (u64)output;
> + hv_ghcb->hypercall.hype
Hi Joerg:
Thanks for your review.
On 8/2/2021 7:53 PM, Joerg Roedel wrote:
On Wed, Jul 28, 2021 at 10:52:16AM -0400, Tianyu Lan wrote:
+static int hyperv_init_ghcb(void)
+{
+ u64 ghcb_gpa;
+ void *ghcb_va;
+ void **ghcb_base;
+
+ if (!ms_hyperv.ghcb_base)
+
On Wed, Jul 28, 2021 at 10:52:20AM -0400, Tianyu Lan wrote:
> +void hv_ghcb_msr_write(u64 msr, u64 value)
> +{
> + union hv_ghcb *hv_ghcb;
> + void **ghcb_base;
> + unsigned long flags;
> +
> + if (!ms_hyperv.ghcb_base)
> + return;
> +
> + WARN_ON(in_nmi());
> +
> +
On Wed, Jul 28, 2021 at 10:52:19AM -0400, Tianyu Lan wrote:
> + if (type == HV_GPADL_BUFFER)
> + index = 0;
> + else
> + index = channel->gpadl_range[1].gpadlhandle ? 2 : 1;
Hmm... This doesn't look very robust. Can you set fixed indexes for
different buffer types?
On Wed, Jul 28, 2021 at 08:29:41AM -0700, Dave Hansen wrote:
> __set_memory_enc_dec() is turning into a real mess. SEV, TDX and now
> Hyper-V are messing around in here.
I was going to suggest a PV_OPS call where the fitting implementation
for the guest environment can be plugged in at boot. Ther
On Wed, Jul 28, 2021 at 10:52:16AM -0400, Tianyu Lan wrote:
> +static int hyperv_init_ghcb(void)
> +{
> + u64 ghcb_gpa;
> + void *ghcb_va;
> + void **ghcb_base;
> +
> + if (!ms_hyperv.ghcb_base)
> + return -EINVAL;
> +
> + rdmsrl(MSR_AMD64_SEV_ES_GHCB, ghcb_gpa);
> +
flight 164077 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164077/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 164061 pass in 164077
test-amd64-amd64-xl-qemuu-debian
flight 164080 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Fri, 2021-07-23 at 11:50 -0600, Logan Gunthorpe wrote:
> Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
> the ->map_sg calling convention, so remove it.
>
> Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
> Suggested-by: Christoph Hellwig
> Signed-off-by:
flight 164078 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164078/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3445058aea4f64a994e4ec040135258a135d36ce
baseline version:
ovmf 610bcc69ed3d1e8c01633
42 matches
Mail list logo
